Re: [PATCH 4/4] fsck: Add support for "completion" scripts.

[Karel Zak <kzak@redhat.com>]

On Wed, Feb 08, 2012 at 08:59:34AM -0800, Frank Mayhar wrote:
> >  The problem is that "device name" is whatever from fsck command line
> >  or from first fstab column.
> > 
> >  Unfortunately the current fsck code does not canonicalize the device
> >  name -- this is bug because in the function ignore() we stat() the
> >  device... I'll fix this problem ASAP.
> 
> If the device name is canonicalized, I think the problem generally goes
> away.

 You miss the point. Yes, we can resolve the problem with UUID= or
 LABEL= in /etc/fstab, but the problem is that nothing guarantees that
 the canonical kernel device name (e.g. /dev/sda) will the same after
 reboot.  This is reason why we use things like UUID= or
 /dev/disk/by-* for block devices.

 Anyway, no problem to support /etc/fsck.d/<devname>/ but preferred and
 recommended will be definitely <uuid>.

> >  Maybe it would be better to somehow standardize the names used for
> >  fsck-log and the completion scripts.
> > 
> >  What about to use
> > 
> >     /etc/fsck.d/uuid/<uuid>
> >     /var/log/fsck/fsck-<uuid>
> 
> Adding the uuid as a potential completion script makes a lot of sense;
> I'm a little hesitant about using the uuid in the logfile name, since
> it's typically pretty long and could easily make the filename unwieldy.
> That's part of what the completion script is for, too:  To potentially
> canonicalize the logfile name into whatever form makes sense locally.
> 
> I would want to keep the devname, fstype and generic completion scripts
> the same, though.  Just add the uuid one as you indicate.
> 
> >  rather than devname? I guess that all usable filesystems provides
> >  UUIDs now and fsck is already linked with libblkid.
> > 
> >  If you agree than ignore this problem for now, I'll implement it.
> > 
> > > +.I system(3)
> > 
> >  Why we need to execute the scripts by system(3)? Why not classic execv?
> 
> The completion script could as easily be an executable binary; I just
> figured I would let system() take care of it for me.  If you have a
> strong objection, I could change it but at the moment I see no strong
> reason to worry about it.
> 
> > > +  /etc/fsck.d/device/hdc1 /dev/hdc1 ext4 0 1.60470 0.41193 0.76588 9828
> > 
> >  I don't like the fixed set of parameters, it will be difficult to extend
> >  such solution in the future.
> 
> Mostly I wanted something that would be trivial to parse.  I thought
> about regular command line options but that makes the completion script
> a lot bigger (all the option-parsing code)

 Good point.

> and my goal was to keep
> things as simple as possible.  Setting environment variables might be
> sufficient, though.
>
> One thing I remembered last night that I forgot to document is that the
> last parameter is optional and is the logfile name (including path) if
> the -L option was given.  I'll generate one more patch to fsck.8 (based
> on the current set of patches) to fix that, although if we go with
> environment variables then it's no longer a problem.
> 
> For my own purposes, I would really like to keep the invocation as-is
> and fall back to environment variables if there are no arguments on the
> command line.  This would make my life a _lot_ easier.

 I understand, but I'd like to have a solution which is usable for
 more people and easy to maintain for upstream :-)  What about

   /etc/fsck.d/completion <devname> <status>

 and the rest of information by FSCK_* env.variables ? The env.
 variables should be pretty simple to use in the script.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com