4 ms·
Is there any way small-scale ~4 drive NAS or file server systems can accommodate SMR drives in software? It looks like they're going to need to do so...
by LeifCarrotson 7y ago
Is there any way small-scale ~4 drive NAS or file server systems can accommodate SMR drives in software? It looks like they're going to need to do so...
- magicalhippo 7y agoA small-scale NAS implies home usage, which again implies plenty of idle time. With plenty of idle time, the SMR drive should perform decent enough, as the drive has enough time to shuffle stuff between the persistent cache region and the SMR region. Or at least that's the theory.
- ubercow13 7y agoThey have problems being chucked out of pools when resilvering, ie. when added to the pool, so the general usage pattern isn't so much the issue as is the way the filesystem or RAID controller reacts to them. In particular I think people have had problems with ZFS because the resilvering process involves a lot of random writes, and once the PMR cache on the drive is full, it will stop responding as it flushes the cache for long enough for ZFS to think it's dead.
- LeifCarrotson 7y agoSo we could make the build process pause until the drive resumed responding, or have the ZFS/whatever filesystem drivers recognize the difference between a dead drive and an SMR drive that's working on its cache? I'd want the drive statistics or benchmarks to include a complete rebuild process, though.
- ubercow13 7y agoYeah, it does seem like maybe there could be improvements on the filesystem/RAID software side to better support these drives. If only they were labelled properly as SMR so that the filesystem devs could buy one to test with.
- toast0 7y agoIt would really be best if the drive properly identified itself, so the host os/filesystem could adapt to the drive parameters. That said, you would want to use a log structured filesystem, with a compaction feature. You want to avoid read-modify-write on the shingled areas, it's time intesive and competes with other I/O.
- loeg 7y agoYou don't need a single Log structure -- the shingle stripes are on the order of 128 MB of or so. Any CoW filesystem can relatively easily adapt to this kind of system; in-place filesystems are basically boned on SMR. The CoW filesystem aren't going to be fast on SMR, mind you, just not quite as awful.
- seized 7y agoExcept filesystems like ZFS are having issues on these SMR Reds during resilvers (rebuilds) because SMR slows down so much.
- Dylan16807 7y ago"Can relatively easily adapt" is not the same as "has already been adapted". It still performs awfully without the work put in to make the hardware and software cooperate, but doing that work is not nearly as big of a burden.
- loeg 7y agoToast0's great-grandparent comment (and my grandparent comment) are talking about Host-managed SMR, not "transparent" drive-managed SMR like these fraudulent WD Reds. Yes, nothing except extremely low load or extremely linear (i.e., security video / tape-style backup) workflows works well with drive-managed SMR.
- ngcc_hk 7y agostorage drive recycle after certain period and hence it is good for the first write but after that as those (and then as which support it) would need to assume low load environment. May be ok, just if we can tell we can test.
- baybal2 7y ago> Is there any way small-scale ~4 drive NAS or file server systems can accommodate SMR drives in software? It looks like they're going to need to do so... The thing is you can't really buy SMR disks that are OS controlled unless you are some big enterprise client. SMR disks discussed here are DM-SMR disks, which basically are same disks, but with a firmware based hack that makes them appear as regular SATA disks.