> Am 14.04.2016 um 01:40 schrieb Daniel Carosone <[email protected]>: > > Yes, agreed and understood. It is a space reservation that ensures some > number of blocks will never be allocated. > > That’s not exactly the same as them never being used, due to CoW updates, but > it's very close. > No, it’s not close at all. It will ensure that, say, only 80% of the block will be allocated, but not which blocks. Over time, all blocks will have been written to, even if 20% of the capacity is free. Then the SSD will not know which 20% of the block that were written are actually free. (Remember, Illumos/Smartos does not do TRIM!) > Once the pool is close to full, any writes that don’t immediately free the > original blocks will get denied. > > The net effect is the same: a relatively constant number of free blocks for > the ssd controller to use in its own wear levelling and performance > management. Overprovisioned storage with lots of spare blocks above whatever > the device keeps internally already. > The free block cannot be used by the SSD controller since it does not know about them. > At least, it seems so to me. My question, elaborated thus, is: what is the > difference you see that makes it insufficient? > > Oh, are we not issuing TRIM from zfs as space is freed? That would explain > it. > YES, this is it. OTOH, using TRIM is not without problems. I read many horror stories on Linux and OSX with TRIM. Apparently some SSDs have firmware bugs in relation to TRIM. For example, I have a number of Samsung 8[45]0 EVO, and they are blacklisted in the Linux kernel source code. I understand that their queued TRIM is buggy. > If so, writing zeros into the reserved space (without compression, dedup, or > snapshots) occasionally will tell the ssd controller the blocks are empty. > Writing zeros does probably not help since to the SSD controller the block will still be used, unless that controller recognizes zeros as free, which again would not be correct since a read from that block still needs to return these zeros. > I feel this is an effective workaround entirely within zfs, without resorting > to the ugly tricks of multiple partitioning schemes and inflexible external > allocations we both dislike. > > On 13 Apr 2016 18:27, "Dirk Steinberg" <[email protected] > <mailto:[email protected]>> wrote: > Am 13.04.2016 um 09:53 schrieb Daniel Carosone <[email protected] > <mailto:[email protected]>>: >> What is wrong with a dataset with refreserv set? >> > It does not actually reserve any specific blocks on the disk (LBAs for SATA) > which would > allow the SSD controller to deduct that a certain part of the SSD is not > being used. > > freservation is purely a (virtual) space accounting method of ZFS. > > smartos-discuss | Archives > <https://www.listbox.com/member/archive/184463/=now> > <https://www.listbox.com/member/archive/rss/184463/24390006-796fb66c> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com/>
------------------------------------------- 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
