How to convert 512e to 4Kn using Fast Format (Seagate Exos X16 drive) ?

[winnielinnie]

Sorry to crash this party, but I feel really stupid right now: I thought setting the ashift to 12 (which is the default value upon pool creation and new vdevs in TrueNAS) makes this entire discussion moot?

With ashift=12, the smallest writable data is 4 KiB, regardless if you're using native 4K or 512e/4K drives. Hasn't this been the situation for several years now?

Am I missing something? I'm happy to learn.

 

[dogwhistle]

Sorry to crash this party, but I feel really stupid right now: I thought setting the ashift to 12 (which is the default value upon pool creation and new vdevs in TrueNAS) makes this entire discussion moot?

With ashift=12, the smallest writable data is 4 KiB, regardless if you're using native 4K or 512e/4K drives. Hasn't this been the situation for several years now?

Am I missing something? I'm happy to learn.

my take on this is...

you should set ashift to match the sector size. if your pool consists of only 512 drives (512e or otherwise), you might as well set ashift to reflect that (ashift=9). in the case of 512e, the drive is emulating 512, so it's still just a 512 sector size disk as far as zfs is concerned, right? although obviously it's smarter to set ashift higher (i.e. ashift=12) if adding 4k drives may ever happen in the future because it seems that the penalty is small for setting ashift too high. the penalty for having ashift set too low is much worse.

setting ashift=12 isn't an appropriate substitute for formatting a compatible drive from 512e to 4kN, though. you're better off actually doing 4kN and ashift=12.

if your disks are 512e, i think the only benefit of ashift=12 over ashift=9 is future proofing the pool so it's possible to add 4k disks later without penalty on them. it doesn't magically give your 512e disks the benefits of 4k sector size.

actually, i recently did ashift=13 on my 4kN pool i just made just in case 8k drives ever happen for me.

please correct me if i'm wrong.

 

[winnielinnie]

although obviously it's smarter to set ashift higher (i.e. ashift=12) if adding 4k drives may ever happen in the future because it seems that the penalty is small for setting ashift too high. the penalty for having ashift set too low is much worse.

It seems this "small penalty" is so inconsequential, that we may as well brush it off as a non-issue.

From the ZFS 101 primer at Ars Technica:

By contrast, there is virtually no penalty to setting ashift too high. There is no real performance penalty, and slack space increases are infinitesimal (or zero, with compression enabled). We strongly recommend even disks that really do use 512 byte sectors should be set ashift=12 or even ashift=13 for future-proofing.

actually, i recently did ashift=13 on my 4kN pool i just made just in case 8k drives ever happen for me.

The last time I created a new pool with TrueNAS was Core 12.0-RELEASE. I don't recall it ever prompting me (nor giving me the option) to set the ashift. Does one have to create it with the command-line, and then later re-import it with TrueNAS?

 

[dogwhistle]

The last time I created a new pool with TrueNAS was Core 12.0-RELEASE. I don't recall it ever prompting me (nor giving me the option) to set the ashift. Does one have to create it with the command-line, and then later re-import it with TrueNAS?

good question.

ashift is actually not exposed in the UI for some dumb reason.

i recently did the following in core 13. here are my notes i took:

on truenas, i created a pool first via webui.
then i did zpool history to see how it was created by webui. copied that command.
then i exported the pool from webui to release it.
i tweaked a couple of settings in the command from zpool history.
made ashift=13 i guess in case i ever want to add 8K sector drives.
then i re-created it from a shell with -f to force it (for safety reasons, it won't re-create a pool from drives used in an existing pool by default).
i didn't want to destroy it first because the webui already nicely partitioned all the drives, and i wanted to keep the gptids on the drives so the command would "just work". that's why i exported instead.

the modified command i used to re-create the pool was this:

Code:

zpool create -f -o feature@lz4_compress=enabled -o altroot=/mnt -o cachefile=/data/zfs/zpool.cache -o failmode=continue -o autoexpand=on -o ashift=13 -o feature@async_destroy=enabled -o feature@empty_bpobj=enabled -o feature@multi_vdev_crash_dump=enabled -o feature@spacemap_histogram=enabled -o feature@enabled_txg=enabled -o feature@hole_birth=enabled -o feature@extensible_dataset=enabled -o feature@embedded_data=enabled -o feature@bookmarks=enabled -o feature@filesystem_limits=enabled -o feature@large_blocks=enabled -o feature@large_dnode=enabled -o feature@sha512=enabled -o feature@skein=enabled -o feature@userobj_accounting=enabled -o feature@encryption=enabled -o feature@project_quota=enabled -o feature@device_removal=enabled -o feature@obsolete_counts=enabled -o feature@zpool_checkpoint=enabled -o feature@spacemap_v2=enabled -o feature@allocation_classes=enabled -o feature@resilver_defer=enabled -o feature@bookmark_v2=enabled -o feature@redaction_bookmarks=enabled -o feature@redacted_datasets=enabled -o feature@bookmark_written=enabled -o feature@log_spacemap=enabled -o feature@livelist=enabled -o feature@device_rebuild=enabled -o feature@zstd_compress=enabled -o feature@draid=enabled -O atime=off -O compression=lz4 -O aclinherit=passthrough -O mountpoint=/mytank -O aclmode=passthrough mytank raidz2 /dev/gptid/f6e04faa-d5b6-11ec-ace5-000c29a25de1 /dev/gptid/f7011d7e-d5b6-11ec-ace5-000c29a25de1 /dev/gptid/f71f0e68-d5b6-11ec-ace5-000c29a25de1 /dev/gptid/f6ed925d-d5b6-11ec-ace5-000c29a25de1 /dev/gptid/f6f5845a-d5b6-11ec-ace5-000c29a25de1 /dev/gptid/f6fb9db1-d5b6-11ec-ace5-000c29a25de1

i also tweaked xattr afterwards.

zfs get xattr showed the default is xattr=on. changing it to xattr=sa and hoping for the best:

xfs set xattr=sa mytank

 

[dogwhistle]

i forgot to add that ashift must be set at pool creation. you can't change it later!

 

[chruk]

my take on this is...

you should set ashift to match the sector size. if your pool consists of only 512 drives (512e or otherwise), you might as well set ashift to reflect that (ashift=9). in the case of 512e, the drive is emulating 512, so it's still just a 512 sector size disk as far as zfs is concerned, right? although obviously it's smarter to set ashift higher (i.e. ashift=12) if adding 4k drives may ever happen in the future because it seems that the penalty is small for setting ashift too high. the penalty for having ashift set too low is much worse.

setting ashift=12 isn't an appropriate substitute for formatting a compatible drive from 512e to 4kN, though. you're better off actually doing 4kN and ashift=12.

if your disks are 512e, i think the only benefit of ashift=12 over ashift=9 is future proofing the pool so it's possible to add 4k disks later without penalty on them. it doesn't magically give your 512e disks the benefits of 4k sector size.

actually, i recently did ashift=13 on my 4kN pool i just made just in case 8k drives ever happen for me.

please correct me if i'm wrong.

As I understand it 512e is a 4k sector disk emulating 512 byte sectors, primarily so very old OS can still use the disk.

So ashift=12 is good enough and will give the same end result, the only real benefit of making the disk 4k native, is you dont need to worry about filesystems accidently formatting it with 512byte sectors because they think the disk is 512 byte native. ZFS been a prime example of auto detection which can go wrong on 512e disks unless you manually specify ashift=12 at pool creation.

 

[fraroy]

Hello,

I have a FireCuda 530 M.2 NVMe which supports 512 and 4096 sector sizes. It comes from factory with 512 sector size. To change to 4096, I used the SeaChest utilities. However the "--setSectorSize 4096" described by the OP does not work. SeaChest_Lite or SeaChest_Format will accept the command but when the timer expires and actual execution is attempted, will return "Setting sector size not supported on this device". It turns out there is a specific operand for NVMe drives: "--nvmFormat". I could successfully change sector size with following command:

SeaChest_Format -d /dev/nvme0n1 --nvmFormat 4096 --confirm this-will-erase-data --poll

--showSupportedFormat confirms the new sector size at 4096:

SeaChest_Lite -d /dev/nvme0n1 --showSupportedFormat /dev/nvme0n1 - Seagate FireCuda 530 ZP1000GM30013 Supported Logical Block Sizes and Protection Types: --------------------------------------------------- * - current device format PI Key: Y - protection type supported at specified block size N - protection type not supported at specified block size ? - unable to determine support for protection type at specified block size Relative performance key: N/A - relative performance not available. Best Better Good Degraded -------------------------------------------------------------------------------- Logical Block Size PI-0 PI-1 PI-2 PI-3 Relative Performance Metadata Size -------------------------------------------------------------------------------- 512 Y N N N Good 0 * 4096 Y N N N Better 0 --------------------------------------------------------------------------------

 

[ricsip]

Sorry to bribg up this old thread, but dobt have any idea for a better place to ask my question:

I have an Exos X18 SATA drive (18TB), that was much cheaper than the then-new X20 series, which is still more expensive and has no obvious (speed/reliability) over the X18 series. I successfully upgraded it from 512E to 4KN mode. Speed difference between 512E and 4KN was literally zero, except some random access test, where the 4KN results were much worse than the 512E ones, but I didnt care much about that.

Now comes my real question: after 4KN conversion, I noticed sunce 2022 October, there were newer firmwares released silently from Seagate for Exos X18: mine was shipped with "SN02" and now the download page offers "SN04".

As usual with this whole IT industry, vendors no longer consider consumers as their partners. So the whole concept of sharing detailed(!) descriptive(!) and meaningful(!) changelogs is a thing of the past nowadays. In Seagates case, there is literally no changelog section in the attached PDFs.

Now comes the billion $ question: does this version include any field-observed bug, that neccessiated a new firmware release issued to the public, that many people would benefit from, if applied to their drives? I am reluctant to go and find some spare 10+ terabytes of spare space just to backup the whole contents of this drive in order to be absolutely safe, in case the firmware update wipes the entire content of the drive. If there was some meaningful changelog, at least I could make an informed decision. But without any hints, thats quite difficult, frankly. Guess I'm just a lame homeuser, whose opinion does not matter on the large scale. On the other habd, how do people in (very) large enteprises/organizations with enormous storage implementations feel in this situation? As I'm quite confident, they dont get the super-secret changelogs from Seagate either? Or do they?

 

[ricsip]

Well, yeah... what did I expect? :(

 

[ChrisRJ]

What do you mean?

 

[Patrick M. Hausen]

@ricsip Did you expect everybody joyning in writing "absolutely no idea"? Drives are black boxes. I buy them, I use them. Only if they misbehave do I contact the manufacturer or check for firmware releases at all. I have 100 servers, probably 500 SSDs in production. I have no idea what firmware any of them is running - apart from the two hypervisor hosts with Intel U.2 enterprise SSDs that lost interrupts and lead to timeouts and controller resets. What was the latest firmware three years ago was flashed, they have working fine since then, whatever ...

This is not intending to play down your concerns, but matter-of-factly I don't have the resources to care about theses things unless some manufacturer messes up big and firmware flaws like "bricked after X hours of service" make the mainstream IT headlines.

 

[diskdiddler]

Sorry to bribg up this old thread, but dobt have any idea for a better place to ask my question:

I have an Exos X18 SATA drive (18TB), that was much cheaper than the then-new X20 series, which is still more expensive and has no obvious (speed/reliability) over the X18 series. I successfully upgraded it from 512E to 4KN mode. Speed difference between 512E and 4KN was literally zero, except some random access test, where the 4KN results were much worse than the 512E ones, but I didnt care much about that.

Now comes my real question: after 4KN conversion, I noticed sunce 2022 October, there were newer firmwares released silently from Seagate for Exos X18: mine was shipped with "SN02" and now the download page offers "SN04".

As usual with this whole IT industry, vendors no longer consider consumers as their partners. So the whole concept of sharing detailed(!) descriptive(!) and meaningful(!) changelogs is a thing of the past nowadays. In Seagates case, there is literally no changelog section in the attached PDFs.

Now comes the billion $ question: does this version include any field-observed bug, that neccessiated a new firmware release issued to the public, that many people would benefit from, if applied to their drives? I am reluctant to go and find some spare 10+ terabytes of spare space just to backup the whole contents of this drive in order to be absolutely safe, in case the firmware update wipes the entire content of the drive. If there was some meaningful changelog, at least I could make an informed decision. But without any hints, thats quite difficult, frankly. Guess I'm just a lame homeuser, whose opinion does not matter on the large scale. On the other habd, how do people in (very) large enteprises/organizations with enormous storage implementations feel in this situation? As I'm quite confident, they dont get the super-secret changelogs from Seagate either? Or do they?

This is a difficult one to answer as there's only so many posters here and it's obscure.

I do recall switching from 512 to 4k being scary at the time for me, it's all working now and I want to leave it alone.
No idea if firmware is an improvement but reddit - datahoarder does have a pretty big following, worth trying there for sure.

 

[ricsip]

This is a difficult one to answer as there's only so many posters here and it's obscure.

I do recall switching from 512 to 4k being scary at the time for me, it's all working now and I want to leave it alone.
No idea if firmware is an improvement but reddit - datahoarder does have a pretty big following, worth trying there for sure.

Thanks, that will be my next attempt.

 

[ricsip]

@ricsip Did you expect everybody joyning in writing "absolutely no idea"? Drives are black boxes. I buy them, I use them. Only if they misbehave do I contact the manufacturer or check for firmware releases at all. I have 100 servers, probably 500 SSDs in production. I have no idea what firmware any of them is running - apart from the two hypervisor hosts with Intel U.2 enterprise SSDs that lost interrupts and lead to timeouts and controller resets. What was the latest firmware three years ago was flashed, they have working fine since then, whatever ...

This is not intending to play down your concerns, but matter-of-factly I don't have the resources to care about theses things unless some manufacturer messes up big and firmware flaws like "bricked after X hours of service" make the mainstream IT headlines.

Are you suggesting that it always has to be catasrophic-level of mess happening, such that only can generate meaningful conversation with (any) vendor? Without colossial f*kups, you can no longer elhave reasonable information sharing expectations from these giant corps?

 

[Patrick M. Hausen]

Well, Intel frequently publishes new firmware for their enterprise SSDs with *some* release notes as does Samsung. I don't know about any other vendor. I was merely stating that I do not follow these and upgrade all my firmware because the upgrade process itself is risky, interrupts customer service, any might cause data loss. I thought you were complaining (a bit) about not getting a reaction in this forum. I suggest most people don't know, and those who know only care to a certain degree. I never used the drives you ask about, so what should I write?

We use ZFS, we have backup procedures, we have been fine apart from that single event with the Intel firmware that was detected during setup and burn in.

 

[AlexGG]

Without colossial f*kups, you can no longer elhave reasonable information sharing expectations from these giant corps?

I would suggest that I am satisfied with the performance of the devices I bought (hard drives or SSDs), or I learn otherwise early on. If I am satisfied after a burn-in, I do not want to hear from the vendor, unless about something catastrophic. Unless they are telling me about a colossal f*kup, my information-sharing mode is that I am not listening. This is a pretty common attitude, as far as I can tell.

 

[Etorix]

Are you suggesting that it always has to be catasrophic-level of mess happening, such that only can generate meaningful conversation with (any) vendor? Without colossial f*kups, you can no longer elhave reasonable information sharing expectations from these giant corps?

For HBAs the policy here is to flash the appropriate P16/P20 IT firmware and then forget about it.
For every other component firmware, including drive firmware, I guess that no-one cares as long as it works. Supermicro even actively warns users NOT to upgrade motherboard BIOS to a later version if the current version does not cause issues.

It's not that we have no reasonable expectations of being informed about changes—indeed, proper documentation is always fine. It is that, unless the change comes with big flashing red warnings about a critical flaw in the earlier version (as was the case with some Samsung SSDs recently), we are not even interested in upgrading. If it ain't broken…

 

[ricsip]

For HBAs the policy here is to flash the appropriate P16/P20 IT firmware and then forget about it.
For every other component firmware, including drive firmware, I guess that no-one cares as long as it works. Supermicro even actively warns users NOT to upgrade motherboard BIOS to a later version if the current version does not cause issues.

It's not that we have no reasonable expectations of being informed about changes—indeed, proper documentation is always fine. It is that, unless the change comes with big flashing red warnings about a critical flaw in the earlier version (as was the case with some Samsung SSDs recently), we are not even interested in upgrading. If it ain't broken…

If it aibt broken....

Yes, Seagate, as every vendor has the exact same approach: if it aint broken, dont touch it. So definitely there has to be something happening that they took the damn effort to release 2 new versions in the past 6 months. But they dont share, why! Maybe pre-failure maintenance or protection has been added? Which -if you miss it- you'll only realise, when its already too late for you &your drive. You are expecting that Seagate would only announce the firmware loudly for customers, if the f*kup is business-affecting (translation: it'll hurt them via increased RMA costs). Otherwise they keep silent equals: the update is no big deal. But still, they have taken the effort, and released something, that may affect many of their users. Theit customers just dont know what they dont know. Its a catch22 situation.

Additionally, the package contains multiple alternate firmwares, that are equally lack any documentation. Seagate just says, you dont need to know anything about these, unless our support tells you otherwise. Nice one, thanks Seagate.

 

[Etorix]

Have you tried asking Seagate about the new version, or are you just auto-radicalising yourself?

 

[ricsip]

Have you tried asking Seagate about the new version, or are you just auto-radicalising yourself?

You know clearly that the Level1 support people have no clue, and by command they dont forward anything to L2 or higher for further progress. Same for WD when I asked about technical sheet of the WD Purple series. Same for Intel when asked for Penryn R0 known issues (errata document).