On 5/17/13 5:29 PM, Chris Murphy wrote: > > On May 17, 2013, at 3:56 PM, Eric Sandeen <sandeen@xxxxxxxxxx> 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 > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
