On Thu, Jun 5, 2014 at 2:53 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Timofey Titovets posted on Thu, 05 Jun 2014 19:13:08 +0300 as excerpted: > >> 2014-06-05 18:52 GMT+03:00 Igor M <igor...@gmail.com>: >>> One more question. Is there any other way to find out file >>> fragmentation ? >>> I just copied 35Gb file on new btrfs filesystem (compressed) and >>> filefrag reports 282275 extents found. This can't be right ? > >> hes, because filefrag show compressed block (128kbite) as one extent. > > Correct. Which is why my original answer had this: > >>>> While compression changes things up a bit (filefrag doesn't know >>>> how to deal with it yet and its report isn't reliable), > > I skipped over the "why" at the time as it wasn't necessary for the then- > current discussion, but indeed, the reason is because filefrag counts > each 128 KiB block as a separate fragment because it doesn't understand > them, and as a result, it's not (currently) usable for btrfs-compressed > files. >
In the context of a compressed database file, the 128 KiB compressed block size has more severe consequences. First, even if the 128 KiB blocks are contiguous, each 128 KiB block has it's own metadata entry. So you already have much higher metadata utilization than without compression. And the metadata can also get fragmented. Every time you update your database, btrfs is going to update whichever 128 KiB blocks need to be modified. Even for a tiny modification, the new compressed block may be slightly more or slightly less than 128 KiB. If you have a 1-2 GB database that is being updated with any frequency, you can see how you will quickly end up with lots of metadata fragmentation as well as inefficient data block utilization. I think this will be the case even if you switch to NOCOW due to the compression. On a very fundamental level, file system compression and large databases are two use cases that are difficult to reconcile. -- 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
