when startup delays become bugs

Eric Sandeen sandeen at redhat.com
Fri May 17 22:45:08 UTC 2013

On 5/17/13 5:29 PM, Chris Murphy wrote:
> 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, 

unclean mount doesn't fail boot ;)

> 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.

Isn't that always the case? :)

Same is true for e2fsck, TBH.  Things can go wrong...

initramfs contains tools for all these filesystems, AFAIK.

-Eric (sorry, I think I'm taking this thread off-topic)

> Chris Murphy

More information about the devel mailing list