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

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



On 10/05/2011 07:21 AM, Lukas Czerner wrote:
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).

fsck should *never* be run on a mounted file system. If that is what you are saying happens, that is 100% a bug and will cause data loss.


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.

We should definitely follow the rules of the file system for when it is safe to resize. Having a clean file system verified by fsck or the checks you mention would both be fine, over riding those checks is not.

I think in general our tools should "do the right thing" and fall back to having a human do manual fsck checks and so on. Running fsck in automatic "yes" mode in a script seems quite iffy to me.

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

If we do need to expand beyond the boundaries of fsadm, that is fine with me. I think that the goal should be to present a pluggable & flexible user command that will work for all local file systems including btrfs so we should not require lvm to be there.

thanks!

ric


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