On Fri, Nov 21, 2014 at 06:22:57AM +0000, Duncan wrote: > After all, an LVM block-level snapshot takes the same space as a file > containing the same raw data, and if there's room for the data in an LVM > snapshot, given a different layout, there's room for exactly the same > amount of data as a file on a different filesystem, piped thru some > compressor if necessary due to tight datasize constraints.
That isn't true at all. A repairing fsck can take less than 1% of the overall volume size, and a full conversion from another filesystem type can take less than 10%. Usually I can find enough space by blowing away the swap LV for a few hours. I do NOT usually have 13TB of slack space lying around in a 26TB disk array, nor do I have enough bandwidth to move those 13TB to another machine without great inconvenience. > But while other filesystems might allow un-UUIDs (heh, UUUIDs or U3IDs > =:^), because they're no longer unique, requiring them to be unique just > as the label says cannot be considered a bug. It's simply stricter > enforcement of the rules, which are, after all, plainly stated in the > descriptive name. It's not a bug as long as I can completely control which devices are searched for UUIDs, and the system behaves sanely when multiple UUIDs are found through automatic discovery; otherwise, it's not only a bug, it's a DoS attack security vulnerability. Consider what happens if someone looks at /sys/fs/btrfs, reads the non-secret UUIDs, builds a fake filesystem with those UUIDs, puts the fake filesystem on a USB stick, and plugs it back into the victim machine... > -- > 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
signature.asc
Description: Digital signature
