It seems I have a few solutions to work with, albeit none that are ideal. I do understand that *ideally* ext4 will automatically force a fsck upon the next reboot after the return of drives that have been unexpectedly "yanked". Historically, though, this doesn't happen.
When we've rebooted (and I'm pretty sure I left this part out in previous descriptions) we have been presented with the directive to manually run fsck. Perhaps this is due to the fact that it is not being told to correct any errors with the -y option which would result in our always booting into rescue mode and manually performing the operation. Perhaps simply adding the /fsckoptions file containing -y will solve the problem. Perhaps not. We are going to evaluate the solutions that have been presented - onerror=panic with the kernel.panic sysctl option set to 0. - tune2fs to set the -c option to 1 which will force a fsck after each mount (ie, each reboot). - creating the /forcefsck file each time the system boots either by way of a cron job which checks for it and creates it if it doesn't exist or simply by way of an entry in /etc/rc.local which touches the file (this will include the /fsckoptions file which will contain the -y option). Again, none are ideal, but the situation is such that we have to pick * something*. Hopefully, we aren't in a position any time soon to be required to test any one of them. -Mathew "When you do things right, people won't be sure you've done anything at all." - God; Futurama "We'll get along much better once you accept that you're wrong and neither am I." - Me On Wed, Oct 30, 2013 at 1:00 PM, Edward Ned Harvey (lopser) < lop...@nedharvey.com> wrote: > > From: Brandon Allbery [mailto:allber...@gmail.com] > > > > On Wed, Oct 30, 2013 at 1:54 PM, Edward Ned Harvey (lopser) > > <lop...@nedharvey.com> wrote: > > I agree, except, that "usable != clean" is irrelevant. The whole point > of the > > journal is that your filesystem doesn't *need* to be clean. Any part of > the FS > > that isn't clean, by definition, you are not using. As soon as you use > it, it > > becomes clean. > > > > This sounds like a severe misunderstanding of how journaling works to > me. It > > is not, in fact, a magic wand that fixes filesystems on the fly; it is a > tool to try > > to avoid corruption and to speed up bringing a filesystem up to date. > And, > > poorly implemented and applied with the mentality you're showing, it is > > quite good at covering up serious corruption until it is far too late to > fix it. > > No. What you said sounds like a misunderstanding. The journal is used to > systematically log the intent to make all changes which could possibly > result in filesystem corruption, if the change were to fail before > completion. Therefore, at a later time, all corruption that could possibly > have been previously introduced is immediately detectable and undoable on > the fly. > > Correct. It's not a magic wand. It's a logical deterministic wand. > > "poorly implemented" is the main thing that makes your paragraph sound > like a misunderstanding. The system administrator doesn't need to do > anything to implement journaling. You just install the OS, including a > journaling filesystem (ext3, ext4, and others) and now your filesystem is > journaling. You have to trust that the kernel and filesystem code > developers released a robust and reliable product. They are the > implementers. > > Also, "covering up corruption until it's too late" seems to demonstrate a > misunderstanding. You're talking about headlight fluid. > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
