when startup delays become bugs

[Chris Murphy]

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.


Chris Murphy