Caveats with the seagate SMR Archive drives.

[Rainwulf]

I have 16 of these in an admittedly too wide vdev, and i was having some serious issues with reading.
see here:
https://forums.freenas.org/index.ph...ormance-with-reading.36846/page-2#post-225426

While i was working on this issue, i noticed an issue with writes to the drives:
https://forums.freenas.org/index.php?threads/whats-writing-all-the-time.36968/#post-225419

Data was being written continuously, but slowly, to the drives. These SMR drives do NOT like being randomly written to, and i was thinking that these writes would be forcing the drives to continuously re-shingle when writing logs.

My freenas system runs of a 120 gig SSD, i have stayed away from USB boot drives after all the horrible things i have heard. So.. i just changed the system dataset pool to the boot drive.

Random writes stopped, read performance is back to being 100 percent!

So yea. Nothing wrong with the drives themselves, but you have to treat them a bit differently. Do not treat them as random access drives, treat them more as write once, read many, (WORM) drives.

As far as i know im one of the first people to have a huge swathe of these things in a single machine, in a single vdev, with only 16 gig of ram. In trying to solve the issues with reading, i updated to 32 gig but that didnt help.
I also set up an L2ARC with another 120 gig SSD and that didnt help either.

So yea guys, if you are using these in a media center, do NOT use them as standard dataset, or a boot drive, or anything involving random access. That also means you should disable all the EA attributes as seen here https://forums.freenas.org/index.ph...-to-improve-samba-browsing-performance.24906/, and also atime.

Beware with removing EA attributes though, some programs get REALLY upset at it, especially backup programs.

 

[Arwen]

You might consider mirroring your FreeNAS boot drive now that you have the System Dataset on it.

I have a Seagate 8TB SMR Archive drive as well. My sole use is backup, which is the opposite use case
than yours, meaning mine is write mostly, read little, (and scrub once a backup).

It would also be worth mentioning certain applications in jails would be better off in normal hard
drive pools or SSD pools. Even if that extra pool was a tiny, (by today's standards), of 64GB.

 

[Rainwulf]

Yep, looking at remove the L2ARC drive now, as its not needed for my uses, and use it as a mirror instead.

 

[Robert Trevellyan]

Random writes stopped, read performance is back to being 100 percent!

Good job figuring this out, and thanks for sharing.

 

[aadje93]

but how is the "actual" performance on the drives? I'm currently investigating this as disks for my 24 disk build, 4 Z2 vdevs of 6 disks, (these). Random IO is not great, but is it truly "shit" so vm's cant run from it. Or is it just not-good? My VM server has 2 sets of 8 10k SAS disks in raid 1+0 for high IO, but i'm planning to run more on the coming ZFS machine, but for the price these are very interesting, the "bare" server is going to cost me around 2K, these drives are cheaper then 6TB wd red's, so thats almost 50% more storage for a cheaper price point, only downside is the supposed lower IO performance, but on the other side i saw a presentation about ZFS being the only suitable filesystem for this kind of drive (SMR)

 

[Arwen]

VMs prefer RAID-1, (and really prefer RAID-10, with as many VDEVs as they can get).

Using SMR drives in a RAID-Z2 for use with VMs may be problematic, even with 4 x VDEVs.
Just too many random writes, topped with random reads.

As for ZFS and SMR, that's IF ZFS was SMR aware. It's not today. My opinion is that SMR
drives should support TRIM / DISCARD, so they can self-optimize. Thus, free space would
be much faster to write on, as it would all continuous space.