> Am 13.04.2016 um 01:22 schrieb [email protected]: > > ----- On Apr 12, 2016, at 6:21 PM, Dirk Steinberg [email protected] wrote: > >> 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 > > > have you seen this? > > https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm > > this seems like it would address your original goal; i'd love to know how to > do the same thing without having to first boot a linux distribution.
I am aware of this. As I said before, I am looking for a simpler solution that does not require partitioning or slicing and definitely does not require booting another OS. I would like to be able to change this via a ssh connection on a running system. Besides, I have 2 other use cases where preallocated zvols would be useful. Said another way: Isn’t ZFS supposed to completely do away with the traditional partitioning and slicing of disks as well as what you would do with traditional LVMs? Well, there are cases where I want exactly what a traditional LVM does: provide a logical block device without any extras like checksumming, COW, snapshots and such. For some applications (few I admit) you simple do not need there features but do care about the last extra bits of performance. To summarize, I’d like to have a zvol type that looks like a plain vanilla traditional logical volume with nailed-down block address maps, no sparse/thin provisioning, no COW, no checksum, no parity. ------------------------------------------- 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
