What's (still) super impressive was the 48 drives. Looking around -the common "Storage" nodes in rack these days seem to be 24x24TB CMR HDD + 2 7.68 TB NVME SDD (and a 960 GB Boot Disk) - I don't know if anyone really uses 48 drive systems commonly (outside the edge cases like Backblaze and friends)
https://www.seagate.com/au/en/innovation/multi-actuator-hard...
Edit: found it (or at least one) "MACH.2 is the world’s first multi-actuator hard drive technology, containing two independent actuators that transfer data concurrently."
World's first my ass. Seagate should know better, since it was them who acquired Connor Peripherals some thirty years ago. Connor's "Chinook" drives had two independent arms. https://en.wikipedia.org/wiki/Conner_Peripherals#/media/File...
That means, if you access files of exactly that size you'd "only" half your iops.
HDDs are quite fine for data chunks in the megabytes.
Exactly. SSD fanboys show me a similarly priced 30 TB SSD and we can discuss. A bit like internal combustion vs e=car - the new tech is in principle simpler and cheaper, in practice simpler and pricier, with the promise of "one day" - but I suppose LCDs were once in a similar place so it may be a matter of time
Make sure to check the "annual powered-on hours" entry in the spec sheet though, sometimes it can be significantly less than ~8766 hours.
You need 2 files, the mount file and the automount file. Keep this or something similar as a skeleton file somewhere and copy over as needed
# /etc/systemd/system/full-path-drive-name.mount
[Unit]
Description=Some description of drive to mount
Documentation=man:systemd-mount(5) man:systemd.mount(5)
[Mount]
# Find with `lsblk -f`
What=/dev/disk/by-uuid/1abc234d-5efg-hi6j-k7lm-no8p9qrs0ruv
# See file naming scheme
Where=/full/path/drive/name
# https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/storage_administration_guide/sect-using_the_mount_command-mounting-options#sect-Using_the_mount_Command-Mounting-Options
Options=defaults,noatime
# Fails if mounting takes longer than this (change as appropriate)
TimeoutSec=1m
[Install]
# Defines when to load drive in bootup. See `man systemd.special`
WantedBy=multi-user.target
# /etc/systemd/system/full-path-drive-name.automount
[Unit]
Description=Automount system to complement systemd mount file
Documentation=man:systemd.automount(5)
Conflicts=umount.target
Before=umount.target
[Automount]
Where=/full/path/drive/name
# If not accessed for 15 minutes drive will spin down (change as appropriate)
TimeoutIdleSec=15min
[Install]
WantedBy=local-fs.targetNow that's still a lot faster than 100MB/s. But I have a lot of recertified drives, and while some of them make the advertised numbers some of them have settled at 100MB/s. You could argue that is something wrong with them, but they are in a raid and I don't need them to be fast. That's what the SSD cache is for.
1: Page 3 https://www.seagate.com/content/dam/seagate/en/content-fragm...
2: Page 2 https://www.seagate.com/content/dam/seagate/en/content-fragm...
3: Page 2 https://www.westerndigital.com/content/dam/doc-library/en_us...
4: Page 7 https://www.seagate.com/content/dam/seagate/assets/products/...
It happens whenever there is a progress indicator. I get obsessed with monitoring and verifying.
If anything the opposite has occurred. HDD scaling has largely flattened. Going from 1986 -> 2014, HDD size increased by 10x every 5.3 years [1]. If anything we should have 100Tb+ drives if scaling kept going. I say this not as a but there have been directly implications for ZFS.
All this data stuck behind an interface who's speed is (realistically after a file system & kernel involved) hard limited to 200MiB/s-300MiB/s. Recovery times sky rocket. As you simply cannot re-build parity/copy data. The whole reason stuff like draid [2] were created is so larger pools can recover in less than a day by doing sequential parity & hot-spairs loaded 1/N of each drives data ahead of time.
---
1. Not the most reliable source, but it is a friday afternoon https://old.reddit.com/r/DataHoarder/comments/spoek4/hdd_cap...
2. https://openzfs.github.io/openzfs-docs/Basic%20Concepts/dRAI... for concept, for motivations & implementation details see -> https://www.youtube.com/watch?v=xPU3rIHyCTs
It kinda sucks that things have flatlined a bit, but still cool that a lot of this has become way cheaper. I think the NVMes at these prices and sizes really makes caching a reasonable thing to do for consumer grade storage
[0] https://www.newegg.com/western-digital-8tb-black/p/N82E16820...
[1] https://www.newegg.com/p/pl?N=100011693%20600551612&Order=1
The biggest cost driver for flash chips is not the speed they can be read from and written to in bursts, but how resilient they are (how many times can they be written over) and sustained speed (both based on the tech in use, TLC, SLC, MLC, 3D NAND, wear levelling logic...): even for SATA speeds, you need the very best for sustained throughput.
Still, SATA SSDs make sense since they can use the full SATA bandwidth and have low latency compared to HDDs.
So the (lack of) price difference is not really surprising.
Please don't perpetuate the weird misconception that "SSD" refers specifically to SATA SSDs and that NVMe SSDs aren't SSDs.
At my first job we paid 6 figures for a 256GB ram machine. Now I see homelabers grabbing old servers with that much memory for their hobby projects.
This offer is already gone but for sure there'll be a new one, VPS prices tend to trend downwards.
I'm sure I'm comprising on reliability but there are going to be part of my hobby K8s cluster so a bit of downtime will make for a nice stress test ;)
It sounds a very good deal - unless they mean 8GB SSD storage, then it’s a normal sort of deal.
Last time I read here HN ZFS still seem have edge case bugs. Has it matured now? Why don't distro such as debian etc just ship ZFS as the default instead of ext4?
I'll tell you why I use it: Built-in compression, and data checksums (so it can catch and potentially correct corruption). Both are extra useful on storage arrays.
> Last time I read here HN ZFS still seem have edge case bugs. Has it matured now?
The only significant bugs I've heard of in a long time are with encryption. Still not ideal, but not a show-stopper.
> Why don't distro such as debian etc just ship ZFS as the default instead of ext4?
(The following is an oversimplification; I'm not a lawyer, so take with grain of salt.) There is, or at least may be, a licensing conflict between ZFS under the CDDL and Linux under the GPLv2. Both good open source licenses, but it is at best unclear that it's legal to distribute binaries that mix code under the two licenses. This makes it at best really messy to distribute a Linux distro using ZFS. (The generally accepted solution is to compile on-device, since the problem only happens with binaries.)
Due to licensing, it can't be included in Linux kernel directly, and so it's not seeing the same level of scrutiny like the rest of the kernel, but it is arguably used in production more successfully than btrfs (comparable feature set, in-kernel, but not maintained as well anymore).