On Tue, Oct 31, 2017 at 5:28 AM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote:
> If you're running on an SSD (or thinly provisioned storage, or something > else which supports discards) and have the 'discard' mount option enabled, > then there is no backup metadata tree (this issue was mentioned on the list > a while ago, but nobody ever replied), This is a really good point. I've been running discard mount option for some time now without problems, in a laptop with Samsung Electronics Co Ltd NVMe SSD Controller SM951/PM951. However, just trying btrfs-debug-tree -b on a specific block address for any of the backup root trees listed in the super, only the current one returns a valid result. All others fail with checksum errors. And even the good one fails with checksum errors within seconds as a new tree is created, the super updated, and Btrfs considers the old root tree disposable and subject to discard. So absolutely if I were to have a problem, probably no rollback for me. This seems to totally obviate a fundamental part of Btrfs design. because it's already been discarded. > This is ideally something which should be addressed (we need some sort of > discard queue for handling in-line discards), but it's not easy to address. Discard data extents, don't discard metadata extents? Or put them on a substantial delay. -- Chris Murphy -- 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
