Re: [PATCH 0/4] Add functions to the fsck wrapper to improve standalone operation.

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

On 02/16/2012 08:17 PM, Frank Mayhar wrote:
> On Wed, 2012-02-15 at 18:42 +0100, Karel Zak wrote:
>> On Wed, Feb 15, 2012 at 04:06:35PM +0000, Pádraig Brady wrote:
>>> On 02/15/2012 03:09 PM, Frank Mayhar wrote:
>>>> 2012/2/15 Pádraig Brady <P@xxxxxxxxxxxxxx>:
>>>>> On 02/07/2012 09:05 PM, Frank Mayhar wrote:
>>>>>> This set of patches adds functions that help improve fsck operation in
>>>>>> large installations and when running in unattended or headless mode.  It
>>>>>> adds support for reporting rusage statistics for the individual fsck
>>>>>> runs, for capturing fsck output, for killing fsck runs that take too
>>>>>> long and for running scripts when each fsck completes.
>>>>>> We're currently using these functions to improve our fsck monitoring
>>>>>> capability and to replace some unwieldy and hard-to-maintain shell
>>>>>> scripts.
>>>>> Couldn't you do this with separate fsck command runs,
>>>>> and use standard system utils?
>>>> Yes, of course.  That's where the "unwieldy and hard-to-maintain shell
>>>> scripts" came in.  Putting the functions in the wrapper itself, on the
>>>> other hand, means the scripts don't have to reimplement functions that
>>>> already exist there (like parallelizing the fsck runs or tracking exit
>>  BTW, the latest fsck supports new -l option (lock disk) for parallel
>>  fsck processes. So you can start arbitrary number of
>>     fsck -l /dev/xxx
>>  without care about performance. We use it for systems with systemd
>>  where fsck is executed per device (fstab entry).
>>  If you want to use the same thing for the classic init scripts then 
>>  you can use something like
>>     for x in $(findmnt --fstab -n -o SOURCE); do
>>         fsck -l $x &< /var/log/fsck-$x &
>>     done
>>  rather tan fsck -A. Add some extra checks (completion scripts) to this
>>  for() should be pretty simple.
> I have to disagree with Pádraig's assertion that the functions are
> supported by "quite simple" shell scripting.  As it turned out, doing
> everything we needed involved a script that was pretty long and
> involved.  (I wish I could share the script with you; it's pretty
> impressive, actually, in a grim and painful kind of way, and a real pain
> to maintain.)  In particular, the short loop you show here and that
> Pádraig used was just not even close to being sufficient.

I still don't see how running a script dependent on the
exit code of fsck, is hard or any different to doing so internally.
Could you give a quick summary of the advantages of pulling
this logic into fsck. Scratch that, you do so below...

I see timeouts and completion scripts etc. as generic functionality.
Pulling stuff like that within commands is less unixy (more coupled) IMHO.

> Further, those of us that are stuck using somewhat older distributions
> don't have some of the newer tools such as findmnt and timeout.

Or newer fsck ;)

>>>> status), eliminates some external dependencies and makes the process
>>>> quite a bit less fragile.
>>> OK, thanks for the clarification.
>>> It seems to me that these functions are supported
>>> by quite simple shell scripting as I demonstrated.
>>  I have no problem with proposed -r option (to report memory and
>>  runtime statistics) and -O option to force-kill fscks that run too
>>  long.
>>  ... but I'm still not sure if we really need the completion script.
> We have to do special stuff if an fsck fails for a particular file
> system.  Without running each fsck individually (something I want to
> avoid for a number of reasons),

please give a couple as this is a crucial point

> how do you propose we do that "special
> stuff" without some command or script that is run by fsck when an
> individual check fails?  In other words, what do you propose I use
> instead of a completion script if I want to use the existing functions
> of fsck for everything else?
> I'm not trying to be rude, by the way (just in case this is coming off
> that way), I'm just trying to point out that in our case we really need
> the completion script and I would bet that there are others out there
> that would find it very useful as well.

I'm not trying to be obstructive BTW.
It just changes like these require appropriate justification.

To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Site Home]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Memory]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Rubini]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]     [Linux Resources]

Powered by Linux