when startup delays become bugs

[Eric Sandeen]

On 5/17/13 3:58 PM, Chris Murphy wrote:
> 
> On May 17, 2013, at 2:38 PM, Ric Wheeler <rwheeler at redhat.com> wrote:
> 
>> On 05/16/2013 02:39 PM, Lennart Poettering wrote:
>>> On Thu, 16.05.13 12:20, Chris Murphy (lists at colorremedies.com) wrote:
>>>
>>>> There have been no crashes, so ext4 doesn't need fsck on every boot:
>>>>
>>>>           4.051s systemd-fsck-root.service
>>>>            515ms
>>>>            systemd-fsck at dev-disk-by\x2duuid-09c66d01\x2d8126\x2d39c2\x2db7b8\x2d25f14cbd35af.service
>>> Well, but only fsck itself knows that and can determine this from the
>>> superblock. Hence we have to start it first and it will then exit
>>> quickly if the fs wasn't dirty.
>>>
>>> Note that these times might be misleading: if fsck takes this long to
>>> check the superblock and exit this might be a result of something else
>>> which runs in parallel monopolizing CPU or IO (for example readahead),
>>> and might not actually be fsck's own fault.
>>
>> We really should not need to run fsck on boot unless the mount fails. Might save some time at the cost of a bit of extra complexity?
> 
> 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.

-Eric


> 
> Chris Murphy
>