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. 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. 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. I guess a btrfs dev should know. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
