On Thu, Nov 20, 2014 at 11:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> > When I have such a filesystem level problem, I simply dd from the backing > device to some other location, generally to a file that's on a different > filesystem (preferrably non-btrfs, I use reiserfs as I've found it very > resilient, here), in which case btrfs device scan won't see the UUID on > the copy as it scans block devices, not inside non-device files. That's hours of dd and you have to find space to do it. > 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's not true for thin volume snapshots. They take up next to no space upon creation, they don't need space reserved in advance. They're more like a qcow2 snapshot than a conventional LVM snapshot; a big difference being if you delete the snapshot, or you delete a bunch of files in a thin volume and follow it with fstrim, the unused extents are returned to the thin pool. There has been a fragmentation problem with thin volumes; I don't know if that's solved yet. And I don't know if it exacerbates things with Btrfs fragmentation. -- Chris Murphy -- 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
