>> I think that you have a problem with extent bookkeeping (if i >> understand how btrfs manage extents). >> So for deal with it, try enable compression, as compression will force >> all extents to be fragmented with size ~128kb. > > No, it will compress everything in chunks of 128kB, but it will not fragment > things any more than they already would have been (it may actually _reduce_ > fragmentation because there is less data being stored on disk). This > representation is a bug in the FIEMAP ioctl, it doesn't understand the way > BTRFS represents things properly. IIRC, there was a patch to fix this, but > I don't remember what happened with it. > > That said, in-line compression can help significantly, especially if you > have slow storage devices.
I mean that: You have a 128MB extent, you rewrite random 4k sectors, btrfs will not split 128MB extent, and not free up data, (i don't know internal algo, so i can't predict when this will hapen), and after some time, btrfs will rebuild extents, and split 128 MB exten to several more smaller. But when you use compression, allocator rebuilding extents much early (i think, it's because btrfs also operates with that like 128kb extent, even if it's a continuos 128MB chunk of data). -- Have a nice day, Timofey. -- 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
