28.11.2016 06:37, Christoph Anton Mitterer пишет: > On Sat, 2016-11-26 at 14:12 +0100, Goffredo Baroncelli wrote: >> I cant agree. If the filesystem is mounted read-only this behavior >> may be correct; bur in others cases I don't see any reason to not >> correct wrong data even in the read case. If your ram is unreliable >> you have big problem anyway. > > I'd agree with that - more or less. > > If the memory is broken, then even without repairing (on read) a > filesystem that is written to will likely be further corrupted. > > > I think for safety it's best to repair as early as possible (and thus > on read when a damage is detected), as further blocks/devices may fail > till eventually a scrub(with repair) would be run manually. > > However, there may some workloads under which such auto-repair is > undesirable as it may cost performance and safety may be less important > than that. > > Thus I think, there should be a mount-option that let users control > whether repair should happen on normal reads or not... and this should > IMO be independent of whether the fs was mounted ro or rw.
If you allow any write to filesystem before resuming from hibernation you risk corrupted filesystem. I strongly believe that "ro" must be really read-only - having separate option to control it will require update of every tool that generates initramfs and even then you cannot avoid using older initramfs with newer kernel. > I'd say the default should go for data safety (i.e. repair as soon as > possible). > Safety means exactly opposite for me - do not modify data if explicitly requested not to do it. Having filesystem in half-read-only state will be too error prone. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
