when startup delays become bugs

[Eric Sandeen]

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
>