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. cheers, Pádraig. -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
