On 24 November 2015 at 04:45, Christoph Anton Mitterer <cales...@scientia.net> wrote: > On Tue, 2015-11-24 at 03:23 +0000, Dimitri John Ledkov wrote: >> btrfs check is a destructive tool, that can attempt repairing btrfs >> filesystem. it should not be run automatically, nor non-interractive, >> nor on each boot. > What source is that information based on? > To my knowledge, and I think I read that even few days ago on the btrfs > mailing list (though I may be mistaken), it's only destructive in case > you run it with e.g. --repair or some other arguments. > > >> ditto xfs_repair. > from the manpage: > -n No modify mode. Specifies that xfs_repair should not modify the > filesystem but should only scan the filesystem and indicate what > repairs would have been made. > > If it may do changes nevertheless, than that's IMHO quite some grave > documentation bug. > > >> they do not, instead they ship fsck.btrfs shell script, that exits >> zero and does nothing. Ditto xfs. > Yes I know, but that also may have been just forgotten to change. > > > Anyway,.. I've wrote a mail to linux-btrfs asking for the plans. > So far Duncan replied that it's probably still not suggested to be run > at boot (though he's only a list regular, not a developer). > We'll see whether one of the devs comments about the long term plans...
Yes, you have three options: - no-opt (exit 0 shell script, fsck(8) compatible maintenance interface) - expensive no-opt (ie. heavy disk io, recalculating and verifying checksums, et.al. which does not modify any datastructures) - destructive, i.e. mutating data structure, operation with repair. Last one is not to be run in an automated¸ non-interractive way. The other two are no-opt, as nothing will actually be done to disk and output hidden behind bootsplashes et.al. -- Regards, Dimitri.
