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. They (the btrfs, filefrag, and kernel folks) are working on teaching filefrag about the problem so it can report correct information, but the approach being taken is to setup generic kernel functionality to report that information to filefrag, such that other filesystems can use the same functionality, which makes it a rather more complicated project than a simple one-shot fix for btrfs by itself would be. So while the problem is indeed being actively worked on, it could be some time before we actually have a filefrag that's accurate in btrfs-compressed-file situations, but once we do, we can be confident the solution is a correct one that can be used well into the future by btrfs and other filesystems as well, not just a brittle hack of a few minutes to a day that can't be used for anything else and that could well break again two kernel cycles down the road. Unfortunately, I know of nothing else that can report that information, so the only real suggestion I have is to either turn off compression or forget about tracking individual file fragmentation for now and go only on performance. But as it happens, the NOCOW file attribute turns off compression (as well as checksumming) for that file anyway, because in-place rewrite would otherwise trigger complex issues and race conditions that are a risk to the data as well as performance, which is why traditional non-COW filesystems don't tend to offer these features in the first place. Btrfs' normal COW nature makes these features possible, but as this thread already explores, unfortunately simply isn't suitable for certain access patterns. So if the file is properly (that is, at creation) set NOCOW, filefrag should indeed be accurate, because the file won't be (btrfs-)compressed. -- 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
