3 ms·
It's mostly sequential performance, but it's also very odd. Deleting a single 2 GB file sometimes takes tens of seconds, or copying files from one volume to ano
by StavrosK 6y ago
It's mostly sequential performance, but it's also very odd. Deleting a single 2 GB file sometimes takes tens of seconds, or copying files from one volume to another will again be extremely slow.. .
- magicalhippo 6y agoIt does sound like fragmentation, which can still happen with a pool that's not filled under the "right" circumstances (usually related to workload vs configuration). But yeah sadly that's the one area where ZFS is less stellar. Once it's fragmented it's hard to fix. Easiest is to send/receive to another pool, but as you note that is not always feasible.
- StavrosK 6y agoIs there no defragmentation tool? I do have lots of free space.
- magicalhippo 6y agoSadly no, not really. Part of it is that it's complicated due to copy-on-write and snapshots. Other part is manpower, it has not been a high-priority issue for most production pools it seems. Google for "block pointer rewrite". Assuming your free space fragmentation is not too bad (check output of zpool list, "frag" column is free space fragmentation level), you could just move files back and forth between the two. Assuming you don't have snapshots holding on to the files, this can help reduce the fragmentation. Otherwise you're stuck with the send/receive. Though I'd try the mailing list[1] to see if any of the gurus can help identify what's going wrong before attempting random ailments. [1]: https://zfsonlinux.topicbox.com/groups/zfs-discuss/ https://zfsonlinux.topicbox.com/groups/zfs-discuss/
- StavrosK 6y agoHmm, I'll try the mailing list, thank you for your help!