12 ms·
15TB HDDs: Western Digital Unveils the Ultrastar DC HC620
- chrisper 8y agoIt's an SMR drive. So better for archiving than regular IO
- deleted 8y ago[deleted]
- Hei1Fuya 8y agoCopy on write filesystems can probably be optimized for SMR by using TRIM commands to punch holes and rewrite the content sequentially in a new zone. Afaik both zfs and btrfs have plans to do this. That way they can be useful for more than archival.
- zzzcpan 8y agoYou probably mean log structured, not copy on write. CoW doesn't help make writes sequential, unlike log structured filesystems.
- aidenn0 8y agolog-structured is a special-case of CoW; specifically it's CoW where the allocation strategy is sequential blocks.
- londons_explore 8y agoI assume that the drive firmware remaps all your writes to make them sequential anyway for increased write performance.
- Hei1Fuya 8y agoFor drive-managed SMR drives, yes, but these seem to be host-managed ones. So the filesystem has to be aware of the zones.
- HankB99 8y ago> ... the filesystem has to be aware of the zones. Does that mean the drives simply will not work with an unaware filesystem or that it will work but performance will be poor?
- gamegoblin 8y agoThey will not work at all. You have to issue special commands to the drive to be able to overwrite zones.
- mjevans 8y agoI was thinking that F2FS might be a good filesystem as a base on which you'd use an object storage abstraction layer (like ceph)... However since I initially saw the news of these drives a few days ago Samsung also axed some Linux devs, which gives me pause and makes me reconsider the long term viability of this filesystem... https://en.wikipedia.org/wiki/F2FS https://en.wikipedia.org/wiki/F2FS
- kdkeyser 8y agoA full blown filesystem is overkill for an object store. You could use something like libzbc ( https://github.com/hgst/libzbc https://github.com/hgst/libzbc ) to write directly to the SMR drives on the block level. I believe Ceph now has abstracted the drives away through BlueStore, which simply puts a large RocksDB database on the drive, bypassing most of the functionality a filesystem offers. It should be much easier to make an SMR compatible version of the LSM-tree backend of RocksDB, than writing a full-blown file system.
- antongribok 8y agoIt's not accurate to say that BlueStore is just a large RocksDB... RocksDB is one of several possible backends for object maps. There is a lot more to BlueStore than just omaps. Also, BlueStore was actually designed with SMR drives in mind, however certain components of it are best placed on solid state media.
- e12e 8y agoStill seems random access might be an issue. But would love to see how eg nilfs2 (maybe on top of software raid) benchmarks against zfs on these big drives.
- orf 8y agohttps://en.m.wikipedia.org/wiki/Shingled_magnetic_recording https://en.m.wikipedia.org/wiki/Shingled_magnetic_recording for anyone else wondering
- deleted 8y ago[deleted]
- astrodust 8y agoNot to be confused with ASMR: https://en.wikipedia.org/wiki/Autonomous_sensory_meridian_response https://en.wikipedia.org/wiki/Autonomous_sensory_meridian_re...
- deleted 8y ago[deleted]
- kdkeyser 8y agoIf you are the target audience for these drives, you likely don't even consider regular (i.e. including random) IO as a use-case for modern HDD's . 10+ TB HDD's really only make sense for sequential IO, even if they technically still support random writes (e.g. the 10 & 12 TB PMR drives): the order of magnitudes of difference in random vs sequential IO performance make this a no-brainer. If you look at the design of, for example, DropBox Magic Pocket, or Infinidat & Qumulo, you'll notice that their HDD access is really as sequential as possible. And if your storage layer is thus already optimized towards sequential writes, why not take the opportunity and get some capacity "for free" by adopting SMR drives?
- marmaduke 8y agoI have a bunch of services running off a 8 12 TB IronWolf Pro array in RAID10, and it does pretty well, even for DB stuff.
- tracker1 8y agoDepends... my NAS is mostly used for video/audio archives and generally only one device in the house using it, playing back a single file, or listing a directory. Would probably be fine in that use case. Beyond that, it's used for backups. Seems like a decent use case. I'm not sure how well they'd work in a NAS with Raid-5/6 though. I'd been considering a new nas with 4-6 drives at 8-12TB already. Random I/O isn't my primary use, and I'm sure there are others at these sizes.
- Latteland 8y agoI am going for the 15tb instead of that 14 so I have extra space for backups. Says no body. We are clearly close to the end of spinning rust, absent some new breakthrough.
- noselasd 8y agoIf I can choose between stuffing 6x15TB or 6x14TB at comparable cost into my NAS, I'd buy the 6x15TB ones.
- WrtCdEvrydy 8y agoBe aware this is an SMR drive, so your writes are going to be heavily limited.
- blattimwind 8y agoSMR is fine for sequential loads, and anything else is not what these are for.
- gsich 8y ago>We are clearly close to the end of spinning rust In every aspect, except price. Samsung 1 TB SSD for 150€, Seagate 8 TB for 220€.
- cm2187 8y agoAgree. And for a NAS the performance of SSD are unlikely to be required. In fact at one point I made the mistake of enabling SSD caching on a NAS. The SSD became the bottleneck because of the limitation of SATA, ie one SSD on SATA is slower than 8 or 10 HD in RAID5. So unless you really need very high iops, HD are likely to be good enough.
- wtallis 8y agoI'm curious who sold you a NAS with SSD caching that didn't support bypassing the cache for sequential I/O. That's a pretty basic and obvious feature, and it seems like the manufacturer must not have been taking their SSD caching feature seriously if they didn't implement bypassing.
- post_break 8y agoWill we hit a point where the size of the drive is simply too big to get the data off in any decent amount of time?
- androidgirl 8y agoTape is already like that.
- a012 8y agoAFAIK new generation of tape has decent read-write speeds.
- astrodust 8y agoDecent for tape, or decent in general?
- gamegoblin 8y agoTape sequential throughput is higher than HDD. It's the latency/seek time that gets you. But for a recovery scenario, you can hopefully just do a giant sequential scan.
- astrodust 8y agoObviously. I mean more like what's the recovery time from tape vs. cheap HDD array?
- ahoka 8y agoIf I did my calculation right it takes more than 16 hours to retrieve all 15T from the driver. Wow!
- a2tech 8y agoI have a lot of places already where recovering from a full wipe is almost not worth it. Customers with 100's of TB of data in 'prosumer' NAS devices that are chock full of regular drives.
- deleted 8y ago[deleted]
- bitL 8y agoI was about to buy 3x 12TB Toshiba for Deep Learning datasets; now I need to reconsider... Does anyone know what are the current reliability stats for >10TB drives? My old 6x 4TB HGST in NAS are running without a single problem for the past 3 years...
- DavidVoid 8y agoThe best resource for that would probably be Backblaze's quarterly hard drive stats. Here are the ones for Q3 2018: https://www.backblaze.com/blog/2018-hard-drive-failure-rates/ https://www.backblaze.com/blog/2018-hard-drive-failure-rates... Scroll down a bit and you'll see the annualized failure rates (AFR). The 10TB and 12TB ones seem to be pretty excellent.
- mnw21cam 8y agoThe counter-point to this is that since Backblaze uses consumer drives, they probably won't ever test these new drives, because they are enterprise.
- DavidVoid 8y agoWould the 10TB Seagate ST10000NM0086 (of which they have 1,220 drives) not count as enterprise ones? Or the 12TB HGST HUH721212ALN604 for that matter.
- wazoox 8y agoExcellent. All recent big disks over 8 TB from all vendors have excellent reliability. HGST/WD Helium drives are particularly good; I configured and installed many hundreds from 6 to 12 TB in the past 4 years, and not a single one failed yet.
- rootw0rm 8y agobefore my current crop of 8TB WD reds, I ran Toshiba enterprise drives and they were extremely reliable for me. none of them failed in a 24x7 hardware raid6 environment after a few years. only replaced them to upgrade capacity.
- quasarj 8y agoSo does anyone know of a way to take a set of files and write them to an HDD, in NTFS or exFAT format, in a single sequential write? Essentially building the FS on-the-fly (because we're talking about datsets that are much too large to fit into memory)?
- Dylan16807 8y agoSo basically a zip file? I will note that you could easily build the MFT before you start transferring data. That's really your active 'dataset' here, and it's not very big.
- quasarj 8y agoBuilding the MFT first is pretty much what I want to do. But I'm not aware of any utilities that can handle it, nor where to start with writing it myself... I have a project where I routinely need to copy large amounts of data (3 to 8 TB) to a hard drive. Problem is, my files are all 512kb. So this is much slower than it could be... If I write it as a single tar file I get excellent throughput, but the users who need to be able to work with the drive are unable to handle a tar file. They need to be able to plug the drive into a Windows computer and have it "just work".. which presents some problems.
- AgentME 8y agoMaybe you could use the same type of filesystem that file CD/DVDs use (UDF?). They're written sequentially and are commonly supported.
- proverbialbunny 8y agoUsing dd. http://man7.org/linux/man-pages/man1/dd.1.html http://man7.org/linux/man-pages/man1/dd.1.html
- Dylan16807 8y agoThat's how you copy an existing filesytem. It's not how you take an arbitrary subset of files and put them into a new filesystem with minimal write amplification.
- femto 8y agoThe 15TB drive packs in 1108 Gbit/inch2. That is, each bit is a square of side 8.5nm. This is small but the transistors in flash are smaller [1]. As mind blowing as the numbers (for both technologies) are in the referenced article, that article is now 2.5 years old. Is anyone aware of more recent numbers? [1] https://www.computerworld.com/article/3030642/data-storage/flash-memorys-density-surpasses-hard-drives-for-first-time.html https://www.computerworld.com/article/3030642/data-storage/f...
- Lramseyer 8y agoFrom my experience in the HDD industry I remember that a magnetic bit of data is about 13-15nm long and about 40-60nm wide (narrower tracks for SMR.) The length of a bit is constrained by the grain size of the magnetic media. However, the width of a bit (prior to SMR) is actually constrained by the size of the write head. I don't remember why, but I think it has to do with the fact that the write current is like 40 mA, and the magnetic flux density on the write element is like 1.5T (no that's not a typo) I'm not an expert on transistor pitches, but here's a chart from Wikipedia for the 10nm - https://en.wikipedia.org/wiki/10_nanometer https://en.wikipedia.org/wiki/10_nanometer It's kind of impressive for HDDs considering that it's a 2 inch long mechanical arm that is able to move with that level of precision.