On 2017-10-31 01:57, Marat Khalili wrote:
On 31/10/17 00:37, Chris Murphy wrote:
But off hand it sounds like hardware was sabotaging the expected write
ordering. How to test a given hardware setup for that, I think, is
really overdue. It affects literally every file system, and Linux
storage technology.
It kinda sounds like to me something other than supers is being
overwritten too soon, and that's why it's possible for none of the
backup roots to find a valid root tree, because all four possible root
trees either haven't actually been written yet (still) or they've been
overwritten, even though the super is updated. But again, it's
speculation, we don't actually know why your system was no longer
mountable.
Just a detached view: I know hardware should respect ordering/barriers
and such, but how hard is it really to avoid overwriting at least one
complete metadata tree for half an hour (even better, yet another one
for a day)? Just metadata, not data extents.
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), 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.
Otherwise, it becomes a question of space usage on the filesystem, and
this is just another reason to keep some extra slack space on the FS
(though that doesn't help _much_, it does help). This, in theory, could
be addressed, but it probably can't be applied across mounts of a
filesystem without an on-disk format change.
--
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
