On 2010-10-22, at 08:32, Lukas Czerner wrote: >>> There is a concern that discard might >>> prevent data recovery after fsck because it might be already discarded >>> (some weird fs corruption?) in pass 5. However in my opinion this is a >>> very small window (if there even is any), because we have already passed >>> check 1-4 and we have just confirmed that group descriptors should be ok. I don't totally agree. When users have a serious filesystem problem, the first thing they normally do is run e2fsck to see if it is corrected (it may even be done automatically at boot after errors=panic causing a reboot. After that, they may want to recover some more data (e.g. with ext3grep, or restore an e2image of the metadata, and re-run e2fsck). If e2fsck will discard all of the data then any data recovery will be impossible. >>> On the other hand there is nothing to be afraid of in the case of mkfs, >>> because we can not possibly lose any relevant data, because discard is >>> done before the filesystem gets created. Well, I've worked several times with users that have accidentally repartitioned and/or reformatted over top of their important data, and it is usually possible to recover some data from this. Again, with discard that would be impossible. I agree that with mke2fs there is less often a need to do that, and the normal intent of mke2fs is to destroy the previously-existing data, which is why I don't totally object to allowing discard by default for it. The intent of e2fsck is different however, since it is usually used for recovery purposes. I'm trying to think of a good heuristic for when discard could be chosen automatically, but have a hard time doing so: - the current heuristic of "no block bitmap errors" is not strong enough... - even a completely clean e2fsck is not sufficient, because sometimes/often in the case of serious corruption a second e2fsck is run to ensure all the problems have been fixed - after "N" consecutive clean e2fsck runs might be enough, but we don't have a counter for that today (but it isn't hard to add, if we are changing the e2fsck code anyway). That said, e2fsck is run so rarely on some systems that this would equate to "never" in some cases Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
