SOLVED Is this a problem?

[DrKK]

What do we think of this.

Exhibit A1:

Code:

[root@daneel] ~# smartctl -a /dev/ada1 | grep -i model
Model Family:  Intel 53x and Pro 2500 Series SSDs
Device Model:  INTEL SSDSC2BW240H6

Exhibit A2:

Code:

[root@daneel] ~# smartctl -a /dev/ada1 | grep -i 'sector size'
Sector Size:  512 bytes logical/physical

And this SSD, as outlined in exhibit A1|2, is a single drive vdev called "ssd", that I use for my jails. Exhibit B:

Code:

[root@daneel] ~# zpool status ssd
  pool: ssd
state: ONLINE
  scan: scrub repaired 0 in 0h2m with 0 errors on Wed May 24 06:02:03 2017
config:

  NAME  STATE  READ WRITE CKSUM
  ssd  ONLINE  0  0  0
  gptid/d0cb19ce-1955-11e6-9094-002590d275c2  ONLINE  0  0  0

errors: No known data errors

But then (and observe that the gptid matches exhibit B, so I am not pulling a fast one on you, Exhibit C:

Code:

[root@daneel] ~# zdb -U /data/zfs/zpool.cache
ssd:
  version: 5000
  name: 'ssd'
  state: 0
  txg: 6638241
  pool_guid: 877894050773353097
  hostid: 128484426
  hostname: ''
  vdev_children: 1
  vdev_tree:
  type: 'root'
  id: 0
  guid: 877894050773353097
  children[0]:
  type: 'disk'
  id: 0
  guid: 11729960411399581475
  path: '/dev/gptid/d0cb19ce-1955-11e6-9094-002590d275c2'
  whole_disk: 1
  metaslab_array: 35
  metaslab_shift: 31
  ashift: 12
  asize: 237905117184
  is_log: 0
  create_txg: 4
  features_for_read:
  com.delphix:hole_birth
  com.delphix:embedded_data

You can see that ashift = 12. i.e., sector size is 4096, even though Exhibit A suggests the sector size is 512 (and that's BOTH physical and logical sector size, so there's no hocuspocus).

This *IS* a problem, right, and explains the ridiculous constant activity on my SSD (esp. deletes) that has been perplexing me for awhile? Yes or no?

I should blow this pool away and start it over with the correct ashift? yes or no? FreeNAS should have done this right in the first place? yes or no?

That is all.

 

[DrKK]

@Ericloewe @joeschmuck @cyberjock @Stux

 

[Ericloewe]

I don't think it will be a problem.

The 512-byte sector size is bogus, anyway. The SSD's pages are much larger than even 4kB, so writes aren't going to magically neatly align to SSD pages - that's something the SSD is going to handle internally in its LBA-to-internal structure mapping and is subject to optimizations such as garbage collection that allow the SSD to operate sorta like an HDD.

This *IS* a problem, right, and explains the ridiculous constant activity on my SSD (esp. deletes) that has been perplexing me for awhile? Yes or no?

No. Worst-case, it might result in some write amplification, but you'd never be able to tell without querying the drive's SMART data and hoping that it reports the quantity of interest.
It will introduce some write amplification at the ZFS layer which may reduce available space (no BPR, no garbage collection, which is SSD speak for clear TRIMmed blocks and group half-empty pages to create fully empty pages - the latter part being the interesting one for ZFS), but it will only be a problem if you consistently have tiny TXGs.
Performance might also see some degradation in a convoluted scenario where the drive is bandwidth limited or IOPS limited despite the fact that you're ending up with tiny ZFS blocks.

 

[joeschmuck]

Here is a link which explains this situation perfectly. First of all, you are perfectly proper in your setup, ashift=12 is proper. The SSD is showing the system a fake 512 byte sector size because it's got an emulator for backwards compatability and a lot of drives do this, however the physical layer is really 4K bytes with lots of 512 byte blocks crammed into it. An ashift of 12 is proper basically for any drive which has native 4K sectors in spite of the emulator.

 

[Stux]

In summary, afaik, you want to use 4096 byte blocks on SSDs.

Clever FreeNAS/ZFS

 

[DrKK]

Here is a link which explains this situation perfectly. First of all, you are perfectly proper in your setup, ashift=12 is proper. The SSD is showing the system a fake 512 byte sector size because it's got an emulator for backwards compatability and a lot of drives do this, however the physical layer is really 4K bytes with lots of 512 byte blocks crammed into it. An ashift of 12 is proper basically for any drive which has native 4K sectors in spite of the emulator.

ok, so then, why is the SSD for the boot pool on ashift = 9, if 12 is proper in almost all cases?

 

[Ericloewe]

It might be that the installer doesn't have the relevant logic and always applies ashift = 9.

 

[rs225]

Agree. The actual page size on SSD is not 512 or 4096, so doesn't make much difference. I personally think ashift=12 is better on SSD because it has the possibility of improving the alignment of writes and increasing contiguity in the mapping table, but it doesn't have as many benefits as on a hard disk.

 

[DrKK]

OK.

I am officially ignoring this then as a non-issue.

Thanks for the input, esteemed colleagues.

 

[Stux]

Sounds like installer needs updating.

Should a flash drive be 512 or 4096?

 

[joeschmuck]

Should a flash drive be 512 or 4096?

Nice way to add more confusion. It doesn't functionally matter thankfully.

 

[Ericloewe]

Now that I think about it, it might help explain why flash drives have such atrocious performance as boot devices...

 

[Stux]

Now that I think about it, it might help explain why flash drives have such atrocious performance as boot devices...

Exactly. Could be a legitimate 'bug' in the installer here.

 

[cyberjock]

What all of them said. It's a non-issue.

I believe that the ashift value has to do with limitations with ZFS booting. You also will find that your boot device may not use compression (first 9.3 builds didn't have support for compressed zpools to be bootable, some later builds finally do), most of the feature flags that are supported aren't enabled, etc.