TR Forums

Waco wrote:

I think it's the convenience actually - I bet 90% of consumer drive sales these days are external drives. We're the oddballs.

True. My in-laws have 4, my parents have two. Neither have bought an internal drive ever that wasn’t installed from the OEM.

Usacomp2k3 wrote:

Waco wrote:

I think it's the convenience actually - I bet 90% of consumer drive sales these days are external drives. We're the oddballs.

True. My in-laws have 4, my parents have two. Neither have bought an internal drive ever that wasn’t installed from the OEM.

How does that explain why they are cheaper than internals now, in spite of including a case and power brick?

just brew it! wrote:

Usacomp2k3 wrote:

Waco wrote:

I think it's the convenience actually - I bet 90% of consumer drive sales these days are external drives. We're the oddballs.

True. My in-laws have 4, my parents have two. Neither have bought an internal drive ever that wasn’t installed from the OEM.

How does that explain why they are cheaper than internals now, in spite of including a case and power brick?

Volume.

If they sell 100x more externals than internals, and only make half the profit on each drive, then they're still making 50x more profit than from their internal drive division.

Also, external drives are front-facing goods. You sell a Seagate external, your friends and relatives see you have a Seagate external, they might think to buy one too. Conversely, if you're Seagate and one of your potential customers buys a WD instead, then /their/ friends and family might now buy WDs instead of Seagates.

The volume is higher, the competition is fiercer, and the loss of mindshare if you lose out to your competitor is more dramatic than with commodity goods like internal hard drives.

Holy crap! Me want:

https://www.qnap.com/en/product/tvs-672xt

So pretty much done. Using Digital Image Mover to finally organize our photo/home video library (It's in the middle of 197k pictures at the moment).
The only thing this can't do that I was hoping it could was run Plex. It just doesn't have the horsepower. Instead, however, I have the desktop setup as the Plex server and it is just using the NAS as a NAS. Gigabit is plenty fast enough, and the desktop is pretty much always on anyway. I haven't tested it, but it should run fine to the AppleTV as well.
In a semi-related note, I just spent $100 on monoprice to buy all new network cables, keystone connectors, wall plates to finally hard-wire everything include 5 rooms, 2 security camera's, and the Access Point. No more random wires running through the ceiling or all on wireless.

Voldenuit wrote:

just brew it! wrote:

How does that explain why they are cheaper than internals now, in spite of including a case and power brick?

Volume.

If they sell 100x more externals than internals, and only make half the profit on each drive, then they're still making 50x more profit than from their internal drive division.

Also, external drives are front-facing goods. You sell a Seagate external, your friends and relatives see you have a Seagate external, they might think to buy one too. Conversely, if you're Seagate and one of your potential customers buys a WD instead, then /their/ friends and family might now buy WDs instead of Seagates.

The volume is higher, the competition is fiercer, and the loss of mindshare if you lose out to your competitor is more dramatic than with commodity goods like internal hard drives.

I suppose there may be something to that. However, given that the drives inside are just normal desktop drives, there's no economy of scale advantage on the production side. But I could definitely see them being willing to take thinner profit margins due to intense price competition in the retail space.

just brew it! wrote:

Voldenuit wrote:

just brew it! wrote:

How does that explain why they are cheaper than internals now, in spite of including a case and power brick?

Volume.

If they sell 100x more externals than internals, and only make half the profit on each drive, then they're still making 50x more profit than from their internal drive division.

Also, external drives are front-facing goods. You sell a Seagate external, your friends and relatives see you have a Seagate external, they might think to buy one too. Conversely, if you're Seagate and one of your potential customers buys a WD instead, then /their/ friends and family might now buy WDs instead of Seagates.

The volume is higher, the competition is fiercer, and the loss of mindshare if you lose out to your competitor is more dramatic than with commodity goods like internal hard drives.

I suppose there may be something to that. However, given that the drives inside are just normal desktop drives, there's no economy of scale advantage on the production side. But I could definitely see them being willing to take thinner profit margins due to intense price competition in the retail space.

Well, if you are not capacity constrained, you have fixed costs in your factories and workers. Your BOM costs may scale linearly (less so with volume discounts) per drive, but you are paying your workers $$$/month whether they are making 10 drives or a thousand, and your factory is similarly the same sunk cost whether you make 10 or a thousand.

just brew it! wrote:

Voldenuit wrote:

just brew it! wrote:

How does that explain why they are cheaper than internals now, in spite of including a case and power brick?

Volume.

If they sell 100x more externals than internals, and only make half the profit on each drive, then they're still making 50x more profit than from their internal drive division.

Also, external drives are front-facing goods. You sell a Seagate external, your friends and relatives see you have a Seagate external, they might think to buy one too. Conversely, if you're Seagate and one of your potential customers buys a WD instead, then /their/ friends and family might now buy WDs instead of Seagates.

The volume is higher, the competition is fiercer, and the loss of mindshare if you lose out to your competitor is more dramatic than with commodity goods like internal hard drives.

I suppose there may be something to that. However, given that the drives inside are just normal desktop drives, there's no economy of scale advantage on the production side. But I could definitely see them being willing to take thinner profit margins due to intense price competition in the retail space.

That simply doesn't make any sense. The external drive contains an internal drive, plus adds a case and power supply. You're literally taking the same thing, adding additional hardware, and selling it for less. There simply is no "volume" that makes that work, logically.

Now, the binning thing I can get. If they take drives that don't pass certain tests, or if they have some stale inventory sitting around where inventory planning did not match orders, then pulling random drives from overstock queues makes sense from a cost-reduction perspective.

End User wrote:

Holy crap! Me want:

https://www.qnap.com/en/product/tvs-672xt

At US$1500 (B&H quote), it looks like building your own might be more economical?

But being compact with their software would certainly bring an advantage...

Buub wrote:

That simply doesn't make any sense. The external drive contains an internal drive, plus adds a case and power supply. You're literally taking the same thing, adding additional hardware, and selling it for less. There simply is no "volume" that makes that work, logically.

Voldenuit already touched on why - nobody is buying internal drives these days, and external drives carry mindshare that even luddites tack on to. Seriously - even tech enthusiasts these days are shucking external drives to save money. I can't remember the last time I bought a new internal HDD, it had to be...at least 6 years ago. Cost per GB is all that matters in this space for enthusiasts. Up front cost and "my tech friend's brother has one" sells all the rest.

Airmantharp wrote:

End User wrote:

Holy crap! Me want:

https://www.qnap.com/en/product/tvs-672xt

At US$1500 (B&H quote), it looks like building your own might be more economical?

Far more. My whole build cost less than that (minus storage) and it can handle 24 drives and a hell of a lot more functionality.

That's always the rub with high-end NAS appliances.

Waco wrote:

Airmantharp wrote:

End User wrote:

Holy crap! Me want:

https://www.qnap.com/en/product/tvs-672xt

At US$1500 (B&H quote), it looks like building your own might be more economical?

Far more. My whole build cost less than that (minus storage) and it can handle 24 drives and a hell of a lot more functionality.

That's always the rub with high-end NAS appliances.

NAS OS?

How much storage do you have in your primary pool?

End User wrote:

NAS OS?

How much storage do you have in your primary pool?

FreeNAS. I'm a ZFS zealot. 8 TB of mirrored system pool, 40 TB of media / read-heavy storage.

The core of your NAS is a 1950X?

What is the additional functionality?

Plex generally beyond basic NAS duty. 4K transcoding is pretty painful in terms of CPU horsepower needed.

just brew it! wrote:

How does that explain why they are cheaper than internals now, in spite of including a case and power brick?

Some of it might be warranty length. While the now-being-phased-out WD Mybooks apparently have a 3-year warranty as the bare NAS drives, the newer and cheaper (at least MSRP) WD Elements seem to be only 2.

Some of it could be binning. For instance the 8TB HGST helium drives found in Mybooks were reported to run at 5400 rpm, while the HGST enterprise drives on which they are based run at 7200.

But I would guess the biggest factor is statistical modelling of failure rates across product lines. On average, consumer externals are likely only used occasionally instead of being in an always-on environment. This is related to the two points above in that fewer drives are RMAd and they can get away with putting lower binned drives that they would otherwise not have a market for.

In reality, most higher end platform drives relegated to external models are probably just as good as their enterprise counterparts (or at least, for my usage, I'd never tell the difference) . I guess I'll see if I'm lucky enough to keep believing this when mine arrive.

Waco wrote:

Plex generally beyond basic NAS duty. 4K transcoding is pretty painful in terms of CPU horsepower needed.

Sorry to be obtuse but I am confused. Plex server and NAS? What does the server boot?

End User wrote:

Waco wrote:

Plex generally beyond basic NAS duty. 4K transcoding is pretty painful in terms of CPU horsepower needed.

Sorry to be obtuse but I am confused. Plex server and NAS? What does the server boot?

FreeNAS is the boot OS. There is a Plex (SMB) plugin.

DancinJack wrote:

End User wrote:

Waco wrote:

Plex generally beyond basic NAS duty. 4K transcoding is pretty painful in terms of CPU horsepower needed.

Sorry to be obtuse but I am confused. Plex server and NAS? What does the server boot?

FreeNAS is the boot OS. There is a Plex (SMB) plugin.

Interesting.

End User wrote:

Waco wrote:

Plex generally beyond basic NAS duty. 4K transcoding is pretty painful in terms of CPU horsepower needed.

Sorry to be obtuse but I am confused. Plex server and NAS? What does the server boot?

FreeNAS. It comes with all sorts of plugins for various NAS duties. Plex is one of the plugins (though I run a custom jail since the plugin for Plex is usually out of date).

Got my 3x 8TB WD MyBook externals. According to Crystal disk info they are WD80EFZX, which are purportedly based on the HGST He 10-8 helium platform. Serial numbers indicate warranties through Oct/Nov 2021 (which I will probably negate due to my inexperience at shucking. We'll see how that goes.

cynan wrote:

Got my 3x 8TB WD MyBook externals. According to Crystal disk info they are WD80EFZX, which are purportedly based on the HGST He 10-8 helium platform. Serial numbers indicate warranties through Oct/Nov 2021 (which I will probably negate due to my inexperience at shucking. We'll see how that goes.

Same drives my buddy just got from shucking his WD externals for a new NAS.

This is really interesting: https://www.usenix.org/system/files/con ... ghayev.pdf

Pay special attention to Figure 1, and how the SMR drives perform. Then take note of the fact that the vertical axis is not linear. Yes, you read that right: throughput well below 30 KB/sec for the Seagate SMR drives, for sustained random write workloads (where "sustained" means more than a minute or so).

This is consistent with the behavior I was seeing with the Seagate ST4000DM004 drives I have.

You can read the rest of the paper too, if you're interested in a decent technical description of SMR and a deep dive into some Linux file system minutiae.

FAST '17 conference paper wrote:

Random writes, however, end up in the persistent cache, dirtying bands. Cleaning a single band typically takes 1-2 seconds, but can take up to 45 seconds in extreme cases.

This may explain why the ST4000DM004 drives kept getting kicked from my home server RAID array. The default timeout for Linux disk operations is 30 seconds.

What typical use pattern would reflect that many sustained random writes?

Usacomp2k3 wrote:

What typical use pattern would reflect that many sustained random writes?

I'm pretty sure I've hit it at least 4 different ways (so far):

1. Rsyncing the contents of my old file server to my new one. Lots of small random writes to update file system meta-data.

2. Recursive MD5 hash of a large directory tree. With default mount options, Linux ext4 will update the "last accessed" time of a file if the previous time it was touched was more than a day ago. So something which you'd naively expect to be a read-only operation actually generates a bunch of small random writes (again to update file system meta-data). Solution is to specify the "noatime" option when mounting, which does not update access time meta-data if the file is only read from.

3. Indexing service. This was actually how my new server reminded me that I'd forgotten to nuke the indexing tool (mlocate) that Ubuntu installs by default. Indexer tripped over the same issue as #2 as it swept through the file system overnight.

4. Disk formatting. By default, Linux ext4 uses what's called "lazy itable init", which means that when you format a new disk it only initializes the bare minimum of data structures to allow the file system to be mounted. The rest of the initialization is done in the background by a low priority thread after the file system is mounted, or as needed if the file system gets a lot of data written to it shortly after being mounted. This allows initial formatting of a new file system to complete in just a few seconds, and is generally a good thing since it allows you to mount and use the file system immediately. Problem is, the writes generated by the background initialization are small enough and come in to the drive slowly enough that you may get into a situation where each one gets flushed to the media individually, with each one triggering a SMR read-modify-write cycle. If you're trying to access the drive while the background init completes (which can take several days!), you'll see highly variable throughput and long pauses where no data at all is being transferred. Disabling the "lazy itable init" feature during formatting seems to eliminate this issue, with the entire disk being initialized and ready to use in under 15 minutes. (So you have to wait a little longer to be able to mount the new file system, but in return you don't need to suffer through several days of crappy even crappier performance while the background initialization completes.)

So basically, these drives are just really sensitive to anything that does non-sequential writes for a non-trivial amount of time. We're talking orders of magnitude performance degradation if you hit one of the bad use cases. And if it is thrashing around doing a lot of SMR read-modify-write cycles, read performance is going to suck too because the OS's I/O queue to the drive gets all backed up, and the drive can't service incoming read requests in a timely manner if it is spending most of its time rewriting SMR bands.

The newer SMR drives have a clever workaround for the things bugging you - the first [some number of GB, I'm not sure if the exact number is NDA] LBAs on the disk are conventionally recorded. This keeps the metadata parts of the FS responsive even with atime updates enabled on most standard filesystems.

The only *real* issue with Seagate SMR drives is that they aren't advertised as shingled and it pisses a lot of people off. If they were simply clear in their damn marketing materials there would be a lot less ill will towards them.

Me? I love them. I'm also managing a population of about 12,000 of them at work and a handful of them at home. I get ~50% of CMR drive speed for sustained write workloads with a well-tuned system. If you use a standard filesystem on the older style drives (I don't know exactly what the switchover point is for consumer drives) you'll have a bad time almost regardless of what you do. In a RAID array they suck massively as well unless you can tune the TLER parameters on the controller to ignore slow drives, but even that is usually pretty painful without the right filesystem on top.

Waco wrote:

The newer SMR drives have a clever workaround for the things bugging you - the first [some number of GB, I'm not sure if the exact number is NDA] LBAs on the disk are conventionally recorded. This keeps the metadata parts of the FS responsive even with atime updates enabled on most standard filesystems.

Might help for NTFS, but ext4 spreads the meta-data across the entire disk, and attempts to keep related data and meta-data physically near each other. This is a reasonable optimization for conventional disks, but problematic on SMR disks.

Waco wrote:

The only *real* issue with Seagate SMR drives is that they aren't advertised as shingled and it pisses a lot of people off. If they were simply clear in their damn marketing materials there would be a lot less ill will towards them.

Yes, it is mostly the fact that I did not realize these were SMR that pisses me off. I would not have bought them in the first place if I had realized how bad they would be for my use case.

Waco wrote:

Me? I love them. I'm also managing a population of about 12,000 of them at work and a handful of them at home. I get ~50% of CMR drive speed for sustained write workloads with a well-tuned system. If you use a standard filesystem on the older style drives (I don't know exactly what the switchover point is for consumer drives) you'll have a bad time almost regardless of what you do. In a RAID array they suck massively as well unless you can tune the TLER parameters on the controller to ignore slow drives, but even that is usually pretty painful without the right filesystem on top.

The key phrase being "well-tuned". I'm not convinced there's a way to get non-sucky performance out of these things with ext4 and/or mdraid unless you've got a very sequential workload. Given that my primary desktop and file server both run Linux, and I have not yet taken the time to learn how to set up or tune ZFS, these drives have been a rather frustrating learning experience. At least they're tolerable as external backups, provided I remember to set the noatime option on mount and disable lazy_itable_init during formatting.

Yep, the marketing was by far their biggest blunder. That and not recommending tuning parameters for common filesystems (or which ones to avoid).

For ZFS they rock given the cheapness. That's not quite as apparent these days now that the WDs have dropped in price, but they used to be cheaper by nearly 40%.

Shucked my drives and set up the QNAP NAS. Everything seemed to work (though I did get a "Fan failed" error when I updated the firmware - I'm not taking this too seriously as the fan seems to be working fine during normal use).

There is a lot to familiarize oneself with the QTS software. I think it is pretty good so far. The one issue is the learning curve insofar as selecting static/thick/thin volume structure in conjunction with QNAPs new "snapshot" roll back functionality. Basically, for those that don't know, snapshopt is in lieu of BTRFS and involves giving up usable volume space to provide block-based meta-data-capture changes to volume contents.

A "static" volume is easy enough - you set a volume size and that's what you get. Business as usual. "Thick" and "Thin" volumes seem to be about providing support for the snapshot function (ie, to allocate space to save the snapshot metadata). I think "Thick" means you define max volume space while setting up the volume and "Thin" means that it can be flexibly assigned afterwards? The trade off being that "Thick" gives you better volume performance (because I guess it's not constantly reading/writing expanding volumes around the snapshot metadata?).

Long story short, I went with RAID 5 array (though RAID 5 gets a bad name with larger arrays due to single redundancy relative to RAID 6, seems to be a reasonable trade off with 3-drive array). This resulted in about 14.55 TB of usable space (3x8TB drives). Then I chose a Thick volume with bytes per "inode" sizes that will result in the volume having a max capacity of 30GB - which I choose to accommodate adding a 4th drive, though I'd probably not expand beyond that any time soon - but many files/directories.. (the optimal choice here wasn't that clear).

I am now attempting to create a Thick volume of max size (Which, as I recall is about 13.5 GB, down from 14.55). I am guessing the lost size is the smallest amount the system allows a Thick volume to set aside for snapshots/other? The whole "Thick" volume is also confusing because the dashboard indicates that my volume is the max potential size (~30GB).

Further, while I am interested in snapshot function, I would really only like to apply it to certain backed up files and photos (and not media such as movies, music). Is this something that would work itself out automatically? Or does this necessitate putting media and backed up files on separate volumes? IE, I don't want snapshots trying to take up large amounts of space if I decide to delete a large video file from the volume...

So yeah.. A bit of a learning curve. And a lot of a ramble.

cynan wrote:

Further, while I am interested in snapshot function, I would really only like to apply it to certain backed up files and photos (and not media such as movies, music). Is this something that would work itself out automatically? Or does this necessitate putting media and backed up files on separate volumes? IE, I don't want snapshots trying to take up large amounts of space if I decide to delete a large video file from the volume...

Snapshots are taken per volume, so if you want to selectively back up photos vs videos, you should store the photos and videos on separate volumes (they can be in the same storage pool). You can, however, restore files from a snapshot on a per-file, per-folder, or the whole volume.

I haven't messed with snapshots in QTS, I'm just using my NAS as a dumb SMB media server and don't really care if anything gets lost or corrupted.