On 5/17/13 3:58 PM, Chris Murphy wrote: > > On May 17, 2013, at 2:38 PM, Ric Wheeler <rwheeler@xxxxxxxxxx> wrote: > >> On 05/16/2013 02:39 PM, Lennart Poettering wrote: >>> On Thu, 16.05.13 12:20, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: >>> >>>> There have been no crashes, so ext4 doesn't need fsck on every boot: >>>> >>>> 4.051s systemd-fsck-root.service >>>> 515ms >>>> systemd-fsck@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 > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
