Hi,
in order to improve long-term performance on consumer-grade SSDs,
I would like to reserve a certain range of LBA addresses on a freshly
TRIMmed SSD to never be written to. That can be done by slicing the
disk and leaving one slice of the disk unused.
OTOH I really like to use whole-disk vdev pools and putting pools
on slices is unnecessarily complex and error-prone.
Also, should one later on decide that setting aside, say, 30% of the
disk capacity as spare was too much, changing this to a smaller
number afterwards in a slicing setup is a pain.
Therefore my idea is to just reserve a certain amount of SSD blocks
in the zpool and never use them. They must be nailed to specific
block addresses but must never be written to.
A sparsely provisioned zvol does not do the trick, and neither does
filling is thickly with zeros (then the blocks would have been written to,
ignoring for the moment compression etc.).
What I need is more or less exactly what Joyent implemented for the
multi_vdev_crash_dump support: just preallocate a range of blocks
for a zvol. So I tried:
zfs create -V 50G -o checksum=noparity zones/SPARE
Looking at „zpool iostat“ I see that nothing much happens at all.
Also, I can see that no actual blocks are allocated:
[root@nuc6 ~]# zfs get referenced zones/SPARE
NAME PROPERTY VALUE SOURCE
zones/SPARE referenced 9K -
So the magic apparently only happens when you actually
activate dumping to that zvol:
[root@nuc6 ~]# dumpadm -d /dev/zvol/dsk/zones/SPARE
Dump content: kernel pages
Dump device: /dev/zvol/dsk/zones/SPARE (dedicated)
In zpool iostat 1 I can see that about 200mb of data is written:
zones 22.6G 453G 0 0 0 0
zones 27.3G 449G 0 7.54K 0 18.9M
zones 49.5G 427G 0 33.6K 0 89.3M
zones 71.7G 404G 0 34.6K 0 86.2M
zones 72.6G 403G 0 1.39K 0 3.75M
zones 72.6G 403G 0 0 0 0
That must be the allocation metadata only, since this is much less than
the 50G, but still a noticeable amount of data. And we can actually see
that the full 50G have been pre-allocated:
[root@nuc6 ~]# zfs get referenced zones/SPARE
NAME PROPERTY VALUE SOURCE
zones/SPARE referenced 50.0G -
Now I have exactly what I want: a nailed-down allocation of
50G of blocks that never have been written to.
I’d like to keep that zvol in this state indefinitely.
Only problem: as soon as I change dumpadm to dump
to another device (or none), this goes away again.
[root@nuc6 ~]# dumpadm -d none
[root@nuc6 ~]# zfs get referenced zones/SPARE
NAME PROPERTY VALUE SOURCE
zones/SPARE referenced 9K -
Back to square one! BTW, the amount of data written for the de-allocation
is much less:
zones 72.6G 403G 0 0 0 0
zones 72.6G 403G 0 101 0 149K
zones 22.6G 453G 0 529 0 3.03M
zones 22.6G 453G 0 0 0 0
So my question is: can I somehow keep the zVOL in the pre-allocated state,
even when I do not use it as a dump device?
While we are at it: If I DID use it as dump device, will a de-allocation
and re-allocation occur on each reboot, or will the allocation remain intact?
Can I somehow get a list of blocks allocated for the zvol via zdb?
Thanks.
Cheers
Dirk
-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription:
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com
