3 ms·
do you have more info on this? I'd love to read a blog post about it. Are there any performance implications to doing ( or not doing ) this?
by fire 4y ago
do you have more info on this? I'd love to read a blog post about it. Are there any performance implications to doing ( or not doing ) this?
- rsync 4y agoWe've started publishing "technical notes" - some of which are always ZFS related: https://rsync.net/resources/notes/ https://rsync.net/resources/notes/ ... we've not disussed this item yet but I am finalizing the most recent "notes" and will include it. If you don't have busy filesystems filling beyond ~90% (used to be 80%...) then I wouldn't ever worry about this. OTOH, if you have very busy filesystems with lots of different consumers and hundreds of millions (or billions) of inodes then a recent dataset might be scattered all over your zpool. There are absolutely performance ramifications to this. So you expand that zpool (you have to expand it for this to work) by adding a vdev, and then you 'zfs send' that dataset onto the same zpool and it will be laid down nice and orderly onto the new free space that was added to the zpool. That dataset will then be more performant. This is analogous to "defrag" as we think of it but, again, in a duct-taped-engineering kind of way.
- kernelbugs 4y agoIs there a way to subscribe to these technical notes postings? I (and I assume others) would be quite interested in being alerted when a new one is posted!
- rsync 4y agoI think the best method would be to follow us (@rsyncnet) on twitter - the publication of these tech notes is one of the very few things we post on that platform ...