[ ... ] >>> Oh please, please a bit less silliness would be welcome here. >>> In a previous comment on this tedious thread I had written:
>>>>> If the block device abstraction layer and lower layers work >>>>> correctly, Btrfs does not have problems of that sort when >>>>> adding new devices; conversely if the block device layer and >>>>> lower layers do not work correctly, no mainline Linux >>>>> filesystem I know can cope with that. >>>>> Note: "work correctly" does not mean "work error-free". >>> The last line is very important and I added it advisedly. [ ... ] >> Filesystems run on top of *block-devices* with a definite >> interface and a definite state machine, and filesystems in >> general assume that the block-device works *correctly*. > They do run on top of USB or SATA devices, otherwise a > significant majority of systems running Linux and/or BSD > should not be operating right now. That would be big news to any Linux/UNIX filesystem developer, who would have to rush to add SATA and USB protocol and state machine handling to their implementations, which currently only support the block-device protocol and state machine. Please send patches :-) Note to some readers: there are filesystems designed to work on top not of block devices, like on top the MTD abstraction layer, for example. > Yes, they don't directly access them, but the block layer > isn't much more than command translation, scheduling, and > accounting, so this distinction is meaningless and largely > irrelevant. More tedious silliness and grossly ignorant too, because the protocol and state machine of the block-device layer is completely different from that of both SATA and USB, and the mapping of the SATA or USB protocols and state machines onto the block-device ones is actually a very complex, difficult, and error prone task, involving mountains of very hairy code. In particular since the block-device protocol and state machine are rather simplistic, a lot is lost in translation. Note: the SATA handling firmware in disk device often involves *dozens of thousands* of lines of code, and "all it does" is "just" reading the device and passing the content over the IO bus. Filesystems are designed to that very simplistic protocol and state machine for good reasons, and sometimes they are designed to even just a subset; for example most filesystem designs assume that block-device writes never fail (that is, bad sector sparing is done by a lower layer), and only some handle gracefully block-device read failures. > [ ... ] to refer to a block-device connected via interface 'X' > as an 'X device' or an 'X storage device'. More tedious silliness as this is a grossly misleading shorthand when the point of the discussion is the error recovery protocol and state machine assumed by filesystem designers. To me it see that if people use that shorthand in that context, as if it was not a shorthand, they don't know what they are talking about, or they are trying to mislead the discussion. > [ ... ] For an end user, it generally doesn't matter whether a > given layer reported the error or passed it on (or generated > it), it matters whether it was corrected or not. [ ... ] You seem unable or unwilling to appreciate how detected and undetected errors are fundamentally different, and how layering of greatly different protocols is a complicated issue highly relevant to error recovery, so you seem to assume that other end users are likewise unable or unwilling. But I am not so dismissive of "end users", and I assume that there are end users that can eventually understand that Btrfs in the main is not designed to handle devices that "lie" because Btrfs actually is designed to use the block-device layer which is assumed to "work correctly" (except for checksums). -- 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
