ZFS reservation: installation guide vs command #15034
-
|
Hi, I know that due to performance degradation with full disk, it is better to reserve some disk quota. In the official installation guides, the tutorials keep 1GiB of free disk at the end of partitions (I mean: 1non-partitioned GB), and a comment says: "At least 1GB". So my question is: is this just a way to do the reservation for the known performance issues? If so, is it the same result of doing a reservation with a command? E.g.: Thank you. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
|
You're conflating a few things here. ZFS, like all filesystems, when very very full, can sometimes run markedly slower, especially with high churn or space fragmentation, in part because you stop being able to reliably find chunks large enough for whatever you're trying to write, and have to start hacking things into smaller chunks, and that's inefficient in a few ways. But that's based on free space in the pool itself, not space ZFS doesn't think it controls on the disk. There are a lot of tutorials for ZFS, so I can't guess which ones you specifically looked at or why they were suggesting that. Setting a reservation or refreservation on a dataset that's doing nothing else would indeed keep a minimum amount free, but ZFS already reserves a chunk of free space to ensure it can always have enough space to free deleted things (among other things), since "never overwriting things in place" means you always need free space in order to do things, and the "slop space" reservation is how OpenZFS avoids being able to fill a filesystem so much you can't delete things due to lack of space. I believe the slop space is capped in recent releases to no more than 128 GiB, as an upper limit, when previously it was just 3.125% of pool space, with no limit. So that should still be a dominating amount of free space on many pools compared to reserving a GB. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, as Rich mentioned, refreservation is too keep some space unallocated
within the pool. Some people try to reserve more than what ZFS does by
default to avoid GANG block creation, which historically caused slow down
in the pools. That's pretty much is trading space for performance.
One GB outside of pool can be another workaround. It is not possible to
shrink a vdev, but disks from different manufacturers can vary slightly in
size. ZFS already reserves small amount of space for the whole disk vdevs,
so that you can replace it with slightly smaller disk from different
manufacturer. If you partition your disk manually, you can create small
partition anywhere in the disk for the same purpose and blocks at the end
are the slowest for HDDs.
…On Thu, 6 July 2023, 18:11 Rich Ercolani, ***@***.***> wrote:
You're conflating a few things here.
ZFS, like all filesystems, when very very full, can sometimes run markedly
slower, especially with high churn or space fragmentation, in part because
you stop being able to reliably find chunks large enough for whatever
you're trying to write, and have to start hacking things into smaller
chunks, and that's inefficient in a few ways.
But that's based on free space in the pool itself, not space ZFS doesn't
think it controls on the disk. There are a lot of tutorials for ZFS, so I
can't guess which ones you specifically looked at or why they were
suggesting that.
Setting a reservation or refreservation on a dataset that's doing nothing
else would indeed keep a minimum amount free, but ZFS already reserves a
chunk of free space to ensure it can always have enough space to free
deleted things (among other things), since "never overwriting things in
place" means you always need free space in order to do things, and the
"slop space" reservation is how OpenZFS avoids being able to fill a
filesystem so much you can't delete things due to lack of space.
I believe the slop space is capped in recent releases to no more than 128
GiB, as an upper limit, when previously it was just 3.125% of pool space,
with no limit. So that should still be a dominating amount of free space on
many pools compared to reserving a GB.
—
Reply to this email directly, view it on GitHub
<#15034 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABXQ6HKS7MWAXSPEAWOEQYTXOZXKBANCNFSM6AAAAAAZ76N7SI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hi, thank you for the clarifications. FYI, I am looking at these tutorials:
So, if I understand correctly your feedbacks:
Did I understood correctly? Thank you, |
Beta Was this translation helpful? Give feedback.
-
|
No. I was saying that a single GiB is probably useless to reserve because your pool has likely already reserved much more than a GiB for its own reasons, so one more isn't going to make that much difference. For example, on a 5TiB pool, 3.125% would be 156 GiB, so you'd either be reserving 128 GiB already (if you have a version new enough to limit the slop space that way) or the whole 156 GiB (if not), either of which is much more than 1 GiB. |
Beta Was this translation helpful? Give feedback.
-
|
Ok now it is clear. |
Beta Was this translation helpful? Give feedback.
No.
I was saying that a single GiB is probably useless to reserve because your pool has likely already reserved much more than a GiB for its own reasons, so one more isn't going to make that much difference.
For example, on a 5TiB pool, 3.125% would be 156 GiB, so you'd either be reserving 128 GiB already (if you have a version new enough to limit the slop space that way) or the whole 156 GiB (if not), either of which is much more than 1 GiB.