how to partition zil ssd drive to underprovision ?

[shannn]

Hi!
I'm new to BSD (mostly do linux) and new to ZFS. I'm testing FreeNAS for possible use as a store in a SMB setting (about 200 users, NFS, Samba, and shared storage for VM disk images - ESXi )

I've read quite a bit about configuring ZFS and am trying to figure out the steps to underprovision a 100GB ssd drive to use for ZIL. My understanding is that underprovisioning can significantly extend the life of the SSD in this setting.
Soo. say I want to create a 60 GB partition on this drive and then configure that as my zil.. do I use gpart to do this? and then how would I add this to my zpool for use as zil?

Thanks.

 

[shannn]

Hi!
I'm new to BSD (mostly do linux) and new to ZFS. I'm testing FreeNAS for possible use as a store in a SMB setting (about 200 users, NFS, Samba, and shared storage for VM disk images - ESXi )

I've read quite a bit about configuring ZFS and am trying to figure out the steps to underprovision a 100GB ssd drive to use for ZIL. My understanding is that underprovisioning can significantly extend the life of the SSD in this setting.
Soo. say I want to create a 60 GB partition on this drive and then configure that as my zil.. do I use gpart to do this? and then how would I add this to my zpool for use as zil?

Thanks.

ok. I messed around and found these commands

gpart add -t freebsd-zfs -l myzil -s 60G -b 1M ada1

ada1p1 added
[root@freenas] /mnt/firstvolgpart show ada1
=> 34 195371501 ada1 GPT (93G)
34 2014 - free - (1M)
2048 125829120 1 freebsd-zfs (60G)
125831168 69540367 - free - (33G)

# zpool add firstvol log /dev/gpt/myzil

# zpool status firstvol
pool: firstvol
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
firstvol ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
gptid/7e8ec410-8d2a-11e2-9e4e-002219d5eba7 ONLINE 0 0 0
gptid/7eeb60b5-8d2a-11e2-9e4e-002219d5eba7 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
da2p2.nop ONLINE 0 0 0
da3p2.nop ONLINE 0 0 0
logs
gpt/myzil ONLINE 0 0 0
​

 

[joeschmuck]

60GB is awful large for a ZIL. I'm not sure that by simply reducing the size of a partition that the SSD will assume it can provision the un-partitioned cells, it's going to be up to the way the firmware was written for that SSD. The firmware may only allow use of a certain section of cells to be used. It's worth investigating but SSD's have a very long life expectancy, something ridiculous that is like 40+ years theoretically (depends on your SSD). Also ensure that your Zpool is V28, not V15. This is very important. If you're using FreeNAS 8.3.x then it will be V28 when you create the pool.

 

[cyberjock]

Honestly, from what I've read, anything bigger than 2-3GB is humongous for servers with only Gb LAN. If you think about it..if you saturate a Gb LAN port, that's about 125MB/sec. So your ZIL would successfully store 24 seconds worth of data. Considering that ZFS tries to "breathe" every 6 seconds or so that's a whole lot of data. Also not everything is stored in the ZIL. I'd expect that if you are actually saturating a Gb LAN alot of stuff is being commited directly to the zpool, but I think you get the point I'm trying to make.

 

[jgreco]

You would need a huge amount of sync write traffic for anything more than a gig or two to have any chance of paying off.

This works out one of two ways, though:

1) ZFS appends contiguous writes to the ZIL, so if you set up a 60GB partition of 100GB, it will slowly work its way through the 60GB and then wrap around, but in the meantime the drive should ALSO be trying to wear-level writes. You've essentially implemented a crude wear-leveling in ZFS by using a far-too-big partition that updates any given section of the partition much less often.

2) If you set up a 10GB partition of 100GB, you give the drive 9/10ths of the space free to manage wear-leveling and failed blocks on its own. In theory these are things that the drive is supposed to be very good at.

You don't really need for your ZIL to be much larger than the maximum size of two transaction groups, because ZFS still requires the physical pool to be updated and does not allow an unbounded number of things to be logged into the ZIL. It is a bit like a sink. If you take a bucket of water and dump it in, you're fine. If you take a firehose and turn it on, you're going to overrun in short order. The controlling factor is the size of the drain and the size of the sink. In a similar manner, a ZIL is awesome at handling some burstiness of sync writes, but your underlying pool design is also very important for sustained performance.

Keeping in mind how a typical SSD works, you're better off starting with a small partition and then enlarging it if need be; this allows the internal wear-leveling to operate optimally, and shouldn't affect your performance.