Sounds like a really good idea!I'll try to implement in in my backup tool, but it might take some time to see real benefit from it (or no benefit:)).
Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora:nazarpc@xxxxxxxxxxxxxxxxxxxxxxx Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF5261249 On 16.03.16 06:18, Chris Murphy wrote:
Very simplistically: visualizing Btrfs writes without file deletion, it's a contiguous write. There isn't much scatter, even accounting for metadata and data chunk writes happening in slightly different regions of platter space. (I'm thinking this slow down happens overwhelmingly on HDDs.) If there are file deletions, holes appear, and now some later writes will fill those holes, but not exactly, which will lead to fragmentation and thus seek times. Seeks would go up by a lot the smaller the holes are. And the holes are smaller the fewer files are being deleted at once. If there's a snapshot, and then file deletions, holes don't appear. Everything is always copy on write and deleted files don't actually get deleted (they're still in another subvolume). So as soon as a file is reflinked or in a snapshotted subvolume there's no fragmentation happening with file deletions. If there's many snapshots happening in a short time, such as once every 10 minutes, that means only 10 minutes worth of writes happening in a given subvolume. If that space is later released by deleting snapshots one at time (like a rolling snapshot and delete strategy every 10 minutes) that means only small holes are opening up for later writes. It's maybe the worst case scenario for fragmenting Btrfs. A better way might be to delay snapshot deletion. Keep taking the snapshots, but delete old snapshots in batches. Delete maybe 10 or 100 (if we're talking thousands of snapshots) at once. This should free a lot more contiguous space for later writes and significantly reduce the chance of significant fragmentation. Of course some fragmentation is going to happen no matter what, but I think the usage pattern described in a lot of these slow down cases sound to me like worse case scenario for cow. Now, a less lazy person would actually test this hypothesis. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message tomajordomo@xxxxxxxxxxxxxxx More majordomo info athttp://vger.kernel.org/majordomo-info.html
Attachment:
smime.p7s
Description: Кріптографічний підпис S/MIME
