[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Storage use cases for the "atomic" command



Vivek Goyal <vgoyal redhat com> writes:

> On Fri, Apr 15, 2016 at 03:53:20PM +0300, Marius Vollmer wrote:
>
> - Status of current configuration
> - Reset the configuration.
> 	- Help users move from loop devices to proper block devices
> 	- Help user tear town existing thin pool and setup a fresh one.
>
> Lot of people have run into issues with second item and anything we can
> do to make user's life easier there, will help a lot.

I am happy to hear that we are on the right track!  Personally, I don't
have any significant experience with Atomic, and really have to rely on
someone identifying the important use cases.

>> With the "devicemapper" backend using a thin pool, "d-s-s reset" would
>>  - rm /etc/sysconfig/docker-storage
>>  - remove the thinpool
>>  - vgreduce all pvs that are now completely empty
>
> This last step is interesting. There are few things to think about.
>
> - Disks might still be busy as they are in use by root lv or some other
>   lv sharing same volume group as thin pool.

Yes.  My current idea is that they will just remain in the pool.  Maybe
we could call "pvempty" first, but maybe that has the risk of a huge
amount of pointless reshuffling.

Leaving a disk in the pool would not count as a failure of the reset
operation, and would be clearly stated in the output.

> - We might have to call "pvremove" explicitly. Not sure if vgreduce will
>   do it automatically.

Pvremove just wipes the signature.

> - If disk is free, then we will have to remove partition also from disk
>   otherwise when dss is run next time, it will complain that disk is
>   already partitioned.

Yes.

> - Wipe all the signatures from the disk so that when dss is run next time
>   it does not complain.

Yes.

> Lot of people want to just reset the docker metadata and thin pool and
> not necessarily free up disk. I am wondering if we should add one more
> option to reset. Simple reset will just cleanup docker data and remove
> thin pool and a deep reset will try to free up the disks and wipe
> partition table and all signatures.

Interesting.  When switching drivers, it is probably convenient to keep
the physical volumes.  Having to add them again is just a nuisance.

>> I don't yet know what "d-s-s reset" could do for other backends or a
>> devicemapper with loopbacks.
>
> For overlay, I think d-s-s reset will simply remove
> /etc/sysconfig/docker-storage and that should be enough.

I think it should also remove /var/lib/docker, for consistency and also
so that people can switch away from the overlay driver.

It might try to shrink the rootfs after removing /var/lib/docker and try
to remove physical volumes.  This might be pointless because xfs can't
be shrunk, but maybe that's a reason to not use xfs.  (Does Atomic use
xfs on /?  I have no idea....)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]