On 2014/10/02 01:31, Duncan wrote:
Niklas Fischer posted on Wed, 01 Oct 2014 22:29:55 +0200 as excerpted:
I was trying to determine how btrfs reacts to disk errors, when I
discovered, that flipping two Bytes, supposedly inside of a file can
render the filesystem unusable. Here is what I did:
1. dd if=/dev/zero of=/dev/sdg2 bs=1M
2. mkfs.btrfs /dev/sdg2
3. mount /dev/sdg2 /tmp/btrfs
4. echo "hello world this is some text" > /tmp/btrfs/hello
5. umount /dev/sdg2
Keep in mind that on btrfs, small enough files will not be written to
file extents but instead will be written directly into the metadata.
That's a small enough file I guess that's what you were seeing, which
would explain the two instances of the string, since on a single device
btrfs, metadata is dup mode by default.
That metadata block would then fail checksum, and an attempt would be
made to use the second copy, which of course would fail it the same way.
At least a very unlikely scenario in production.
And that being the only file in the filesystem, I'd /guess/ (not being a
developer myself, just a btrfs testing admin and list regular) that
metadata block is still the original one, which very likely contains
critical filesystem information as well, thus explaining the mount
failure when the block failed checksum verify.
This is a possible use-case for an equivalent to ZFS's ditto blocks. An
alternative strategy would be to purposefully "sparsify" early metadata
blocks (this is thinking out loud - whether or not that is a viable or
easy strategy is debatable).
In theory at least, with a less synthetic test case there'd be enough
more metadata on the filesystem that the affected metadata block would be
further down the chain, and corrupting it wouldn't corrupt critical
filesystem information as it wouldn't be in the same block.
That might explain the problem, but I don't know enough about btrfs to
know how reasonable a solution would be.
[snip]
A reasonable workaround to get the filesystem back into a usable or
recoverable state might be to mount read-only and ignore checksums. That
would keep the filesystem intact, though the system has no way to know
whether or not the folder structures are also corrupt.
I'm not sure if there is a mount option for this use case however. The
option descriptions for "nodatasum" and "nodatacow" imply that *new*
checksums are not generated. In this case the checksums already exist.
--
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97
--
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
