On Tue, Jul 03, 2012 at 07:37:42PM +0200, David Sterba wrote:
> On Tue, Jul 03, 2012 at 09:26:41AM -0700, Zach Brown wrote:
> > On 07/03/2012 08:52 AM, David Sterba wrote:
> > >--- a/btrfsck.c
> > >+++ b/btrfsck.c
> > >@@ -3474,6 +3474,7 @@ static struct option long_options[] = {
> > > { "repair", 0, NULL, 0 },
> > > { "init-csum-tree", 0, NULL, 0 },
> > > { "init-extent-tree", 0, NULL, 0 },
> > >+ { "force", 0, NULL, 0 },
> >
> > If we were to run with this, I think it should be called something other
> > than force. fsck.ext* has trained people to think that 'forcing' a fsck
> > means doing a full repair pass even if the fs thinks that it was shut
> > down cleanly.
>
> Agreed, it's not a good name and was rather a quick aid to myself, I
> didn't put much thinking into the user interface as I usually do :)
xfs_repair uses:
-d Repair dangerously. Allow xfs_repair to repair an
XFS filesystem mounted read only. This is typically
done on a root fileystem from single user mode,
immediately followed by a reboot.
> > --read-only would be good if fsck was taught to not even try to write in
> > this mode.
>
> read-only mode is default and (hopefully) does no writes to the device,
> this would require the --repair option so what you propose is sort of a
> sanity check, right?
If you run fsck/reapir on a mounted filesystem, and it changes the
block device (i.e. fixes something) the mounted filesystem does not
know about it and so may use stale metadata and bad things will
happen. That's why it's called "dangerous". ;)
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
