[lvm-devel] [PATCH v3 01/18] fsadm: Add new commands create, list, add and remove

[Lukas Czerner]

On Wed, 5 Oct 2011, Alasdair G Kergon wrote:

> On Wed, Oct 05, 2011 at 11:46:45AM +0200, Lukas Czerner wrote:
> > On Wed, 5 Oct 2011, Zdenek Kabelac wrote:
> > > Dne 5.10.2011 10:02, Lukas Czerner napsal(a):
> > > > On Tue, 4 Oct 2011, Zdenek Kabelac wrote:
> > > > > Dne 4.10.2011 14:13, Lukas Czerner napsal(a):
> > > > > > On Tue, 4 Oct 2011, Zdenek Kabelac wrote:
>  

Hi Alasdair,

> You both lost me several messages ago!
> 
> For *changes* to functionality, what I'm looking for is:
> 
>   Description of how it works today in *all* relevant code paths/option
> combinations/invocation methods;
> 
>   Description/explanation of how it will work *after* the change has been made
> in all the same cases as now plus any new ones
> 
> Explanation of/justification for the difference.
> 
> Currently in lvm:
> 
>   --yes is meant to mean 'answer yes to all questions'
> These are generally informative questions telling the user what the tool will do
> and seeking confirmation.  On its own, they should not be dangerous or risk
> corruption.  Example: removing an LV that is active but not currently being used.
> The idea of such questions is to point out to the user the actual consequences
> of the command to help to make sure they understand what will happen.
> 
>   --force is meant to mean 'permit operations that might not always be wise but
> sometimes do need to be done - assume the user knows what they are doing'.
> Normally a warning of what will happen is issued and confirmation is required,
> but --yes can be used to avoid that confirmation.

Do you mean --force in the last sentence ?

> 
> For dangerous things that wouldn't normally make sense but occasionally can be
> justified, like destroying PVs while they are in (inactive) VGs, --force can be
> required to be repeated twice.
> 
> 
> Now, let's try to understand:
>   How these options are currently used in fsadm-related tools;
>   What's good/bad here and perhaps ought to change.
> 
> Alasdair
> 

The first misunderstanding was the use of -f in lvm toos. Because I can
not see -y|--yes in the documentation I simply used force for not asking
questions about active volumes to be removed. This can be fixed, if '-y'
really works.

The other is, that using -y option to answer yes to umount mounted file
system to be checked is ok, but then running fsck with that '-y' option
does not make sense and it is also dangerous. But Zdenek is convinced
that it has to stay there (I say it is a bug).

And lastly, the problem with using --force to skip the fsck before
attempt to resize the file system. Using force in my opinion does not
imply skipping fsck, and I believe that is how it is implemented in
lvresize as well, where you have to use "--nofsck" (which is broken btw).

I believe that fscking file system before the resize is the right thing
to do and I do not see any reason to allow it to be overridden in fsadm,
although we probably should check for 'last mount' and 'last check' fs
attributes to see if it was checked after the last mount and fsck it
otherwise.

Generally the problem is that we could not agree on almost anything and
due to 'it stays as it is, deal with it' altitude it seems to be that
even the discussion is not allowed.

Honestly, when I started to poke the fsadm I quickly realized that if I
am going to improve the functionality in the bigger scale, it will be
more and more painful to do this in Bash. So maybe it will be easier for
both sides to just forget about fsadm and make a separate project for
example in Python. Because after all I would like this tool to be able
to manage btrfs as well someday and since that does not have anything to
do with lvm, I fear that it will be a major problem to get this into
upstream fsadm. So what people think ?

Thanks!
-Lukas