Reservations against ZFS over-filling collapse

[Jim Klimov]

Hello all,

"It is known" that after a ZFS pool has reached some degree of
fullness (70% for some cases, 95% for some others), performance
radically drops due to lack of large-enough contiguous free spaces
and growing fragmentation on reads and longer seeks/traversals on
writes...

Would it help to pre-create a volume which does not allocate
disk space with any data, but does reserve some 5% or 25% of the
pool so that nobody can write there - this way keeping some space
available against the performance collapse?

I believe there is some reservation (1/64th of the pool) in place
already, which often amounts to quite a hefty piece of disk space.
What exactly does it do, and why does it not help (much) in this
case? :)

Thanks,
//Jim

[Paul Kraus]

Post by Jim Klimov
Would it help to pre-create a volume which does not allocate
disk space with any data, but does reserve some 5% or 25% of the
pool so that nobody can write there - this way keeping some space
available against the performance collapse?

I have been creating a zfs dataset that remains unmounted (no mount point set) which has a reservation of 1 GB (or less for small zpools). I do this for protection against a FULL dataset, not for performance reasons. This has bailed my butt out of trouble at least once when a rouge process filled a dataset. I scaled back the reservation and was able to remove some files from the FULL dataset.

Creating a reservation dataset (I name mine "do-not-remove") in order to preserve performance at the cost of capacity is an interesting idea.

--
Paul Kraus
Deputy Technical Director, LoneStarCon 3
Sound Coordinator, Schenectady Light Opera Company

[Jim Klimov]

Post by Paul Kraus

Post by Jim Klimov
Would it help to pre-create a volume which does not allocate
disk space with any data, but does reserve some 5% or 25% of the
pool so that nobody can write there - this way keeping some space
available against the performance collapse?

I have been creating a zfs dataset that remains unmounted (no mount point set) which has a reservation of 1 GB (or less for small zpools). I do this for protection against a FULL dataset, not for performance reasons. This has bailed my butt out of trouble at least once when a rouge process filled a dataset. I scaled back the reservation and was able to remove some files from the FULL dataset.

Good point, but I do that as well :)

This helps especially against problems with deletion of files from full
datasets *with snapshots* on full pools.
//Jim

[Saso Kiselkov]

Post by Jim Klimov
Hello all,
"It is known" that after a ZFS pool has reached some degree of
fullness (70% for some cases, 95% for some others), performance
radically drops due to lack of large-enough contiguous free spaces
and growing fragmentation on reads and longer seeks/traversals on
writes...
Would it help to pre-create a volume which does not allocate
disk space with any data, but does reserve some 5% or 25% of the
pool so that nobody can write there - this way keeping some space
available against the performance collapse?

How about:

# zfs create -V $(zfs get -pHo value used,available $POOL_NAME | awk
'{total += $1} END{printf("%d\n", rshift(total / 10, 30));}')G
$POOL_NAME/.balloon

I fail to see a reason why this wouldn't work.