when startup delays become bugs

Chris Murphy lists at colorremedies.com
Fri May 17 22:29:41 UTC 2013


On May 17, 2013, at 3:56 PM, Eric Sandeen <sandeen at redhat.com> wrote:

> On 5/17/13 3:58 PM, Chris Murphy wrote:
>> 
>> Seems some extra complexity is needed anyway since the way to deal
>> with file system problems differs with the various fs's. XFS and
>> Btrfs fsck's are noops. XFS needs xfs_repair run, and Btrfs maybe
>> needs to be remounted with -o degraded, depending on the nature of
>> the mount failure since most problems are autorecovered from during
>> mount.
> 
> fsck.xfs is a no-op because of the xfs approach that it's a journaling
> filesystem, so the mount-time recovery is simply "replay the log you're
> good."
> 
> If you have a corrupt filesystem (as opposed to a not-cleanly-unmounted
> filesystem), xfs_repair is an administrative action,
> not a boot-time auto-initiated initscript action.

So if the boot fails due to reasons other than an unclean mount, with xfs the user needs a rescue environment of some sort. At the moment, it's similar with Btrfs in that what to do next depends on the problem.


Chris Murphy


More information about the devel mailing list