Erkki Seppala posted on Mon, 21 Sep 2015 23:35:39 +0300 as excerpted: > Gareth Pye <[email protected]> writes: > >> People tend to be looking at BTRFS for a guarantee that data doesn't >> die when hardware does. Defaults that defeat that shouldn't be used. > > However, data is no more in danger at startup than it is at the moment > when btrfs notices a drive dropping, yet it permits IO to proceed. Is > there not a contradiction?
The problem at runtime is that btrfs _doesn't_ really notice a device dropping. It simply continues writing to the existing devices, and buffering the data for the now missing device. The block device management parts of the kernel know it's missing (the device node will disappear from devtmpfs, etc), but the btrfs part carries on, oblivious. At mount, however, btrfs notices (since it must as it's trying to assemble the filesystem at that point), and refuses to mount without the degraded option if there's too many devices missing. I'd argue that noticing the problem and requiring admin intervention to avoid risk to the data is a feature, not a misfeature, and that the runtime behavior is therefore ultimately a lacking feature, ultimately a bug which should be fixed, while you seem to be arguing that carrying on oblivious is the feature, and requiring admin intervention when there's a risk to data is a misfeature, ultimately a bug that should be fixed. =:^\ -- 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
