Unable to create Pool with ashift=14

All your general support questions for OpenZFS on OS X.

Unable to create Pool with ashift=14

Postby mike0810 » Wed Aug 05, 2015 1:10 am

Try to create a pool with 6 mx200 260GB Crucial SSDs.

The 16nm Micron Nand have reportedly a Page Size of 16K:
http://www.anandtech.com/show/7147/micr ... ds-in-2014

So I tryed to create my pool with:
sudo zpool create -f -o ashift=14 -O casesensitivity=insensitive -O normalization=formD fast raidz2 disk4 disk5 disk6 disk7 disk8 disk9
cannot create 'fast': property 'ashift' number 14 is invalid.
mike0810
 
Posts: 55
Joined: Fri Jan 16, 2015 5:17 pm

Re: Unable to create Pool with ashift=14

Postby Brendon » Wed Aug 05, 2015 1:57 am

I thought SSDs were ashift=13?

Having said that I will take a look at the code and see what the rules are. (outcome: 9-13 inclusive are the valid ashift values).

Cheers
Brendon
Brendon
 
Posts: 286
Joined: Thu Mar 06, 2014 12:51 pm

Re: Unable to create Pool with ashift=14

Postby mike0810 » Wed Aug 05, 2015 2:12 am

Hi, I thought ashift depends on the Page Size. The 16nm Micron NAND have Page Size of 16K.
Regards,

Mike
mike0810
 
Posts: 55
Joined: Fri Jan 16, 2015 5:17 pm

Re: Unable to create Pool with ashift=14

Postby Brendon » Wed Aug 05, 2015 2:39 am

Yep ok we will look into this.

Brendon
Brendon
 
Posts: 286
Joined: Thu Mar 06, 2014 12:51 pm

Re: Unable to create Pool with ashift=14

Postby rottegift » Thu Sep 03, 2015 2:31 am

The problem with bigger ashifts is that the smallest possible writes get inflated.

For instance, with ashift=9, and the embedded_data and lz4_compress features enabled on the pool, you get lots of small (zfs) metadata occupying half the space it would otherwise. This savings vanishes as ashift grows above 9.

Additionally, when you have compression enabled in a dataset, you cannot squish highly compressible data down to less than 16k, so you will get extra space consumed by the tail ends of files. As ashift climbs above 12, it gets really noticeable.

You should check the smallest LBA block size offered by your ssd (it'll be one of 512 or 4096), and adjust your ashift to that (ashift=9 or ashift=12). zfs has some clever logic to try to sequentialize random reads and writes, so even if you are using ashift=9, you will probably be sending your ssds longer strings of LBAs together in practice anyway. Additionally, modern ssds do a variety of things to mitigate truly random writes, even fairly small ones, especially if there is internal overprovisioning (this can be set in most modern ssds, and in many cases there is some already built-in and configured). There may be no significant ashift-related performance difference for most loads on a relatively empty zfs pool made out of modern ssds. Moreover, ashift=9 means your data will take less actual space than ashift=12 or higher, which (a) is often attractive on its own since ssds are relatively small and (b) the zfs allocator can do a better job for the same amount of pool data.

tl;dr: test performance of ashift=9 and ashift=12 before you go up to ashift=14, unless you are drowning in raw ssd storage space.
rottegift
 
Posts: 26
Joined: Fri Apr 25, 2014 12:00 am


Return to General Help

Who is online

Users browsing this forum: No registered users and 34 guests

cron