Western Digital Continues Working On SMR / Zoned Device Support For Btrfs

[phoronix]

Phoronix: Western Digital Continues Working On SMR / Zoned Device Support For Btrfs

In addition to SUSE continuing to advance the Btrfs file-system, Western Digital has also been working on a big patch series around providing native support for zoned block devices...

http://www.phoronix.com/scan.php?page=news_item&px=Btrfs-Zoned-Block-Device-V2

[boxie]

well, that might be the cause of my latency problems with btrfs raid...

[tildearrow]

Do these new hard drives have more reliability issues?

[SpyroRyder]

Do these new hard drives have more reliability issues?

Depends on if you consider abdolutely fucked write times an issue. A friend of mine got a 4TB seagate SMR drive and it took him 2 days to copy over ~700gigs. On my old seagate 2TB it took just over 5 hours

[S.Pam]

So what are these new commands? What does Zoned mean?

[Guest]

Wouldn't tape be better at this point? I guess hard disks will try to stay relevant for archival purposes, but I wonder whether they're the best solution, considering they're whole device with moving parts, and there are plenty of ways in which they can fail. It would make sense to go back to days of having platters separated from the mechanism.

[elatllat]

SMR is only slower for random IO, not a big linear copy.

tape is not a usabe substitute.

I assume the new commands reduce write time by letting the fs and disk driver communicate what data requires re-write on overlapping change, maybe padding for high re-write data.

[rene]

SMR is only slower for random IO, not a big linear copy.

tape is not a usabe substitute.

I assume the new commands reduce write time by letting the fs and disk driver communicate what data requires re-write on overlapping change, maybe padding for high re-write data.

yeah, however, even big linear copy of big files (e.g. videos) over SMB (Samba) is not that linear and rather slow, and an ssd based dm-cache does not help much. Unfortunately I did not immediately realise this when I purchased two 4TB 2.5" drives, and I think those drives do not yet support those new commands to help Linux tune that either – they also parked their heads rather often :-/ https://www.youtube.com/watch?v=UdBrV7NXBFg

[NotMine999]

It would be nice when people talk about "slow" and "latencies" that they provide accurate, measured and repeatable tests and test data to justify their claims.

Otherwise they are all just "vaping"....

[AndyChow]

SMR is about the same speed as a regular drive, except when you fill the buffer. A drive will typically have a 200+ GB buffer area, where it will write whatever it needs to re-write that doesn't fit in a shingled section. As soon as the io of the drive goes down, the drive will re-write the shingled areas and empty the buffer. The problem occurs if you have an active drive where the buffer is almost full, and then you write a huge sequential file. The drive won't find an empty area to write the whole file, so it will fill the buffer, the buffer will then empty a single track, and it will repeat this, going from 180 MBps usual to 40 MBps at most. Because it's doing write-read-write on three different disk sections.

Otherwise, as backup drives, or write-few read-many, they are fantastic drives.