SoylentNews is people
SoylentNews
ZFS versus RAID: Eight Ironwolf disks, two filesystems, one winner:
This has been a long while in the making—it's test results time. To truly understand the fundamentals of computer storage, it's important to explore the impact of various conventional RAID (Redundant Array of Inexpensive Disks) topologies on performance. It's also important to understand what ZFS is and how it works. But at some point, people (particularly computer enthusiasts on the Internet) want numbers.
First, a quick note: This testing, naturally, builds on those fundamentals. We're going to draw heavily on lessons learned as we explore ZFS topologies here. If you aren't yet entirely solid on the difference between pools and vdevs or what ashift and recordsize mean, we strongly recommend you revisit those explainers before diving into testing and results.
And although everybody loves to see raw numbers, we urge an additional focus on how these figures relate to one another. All of our charts relate the performance of ZFS pool topologies at sizes from two to eight disks to the performance of a single disk. If you change the model of disk, your raw numbers will change accordingly—but for the most part, their relation to a single disk's performance will not.
[It is a long — and detailed — read with quite a few examples and their performance outcomes. Read the 2nd link above to get started and then continue with this story's linked article.--martyb]
Previously:
(2018-09-11) What is ZFS? Why are People Crazy About it?
(2017-07-16) ZFS Is the Best Filesystem (For Now)
(2017-06-24) Playing with ZFS (on Linux) Encryption
(2016-02-18) ZFS is Coming to Ubuntu LTS 16.04
(2016-01-13) The 'Hidden' Cost of Using ZFS for Your Home NAS
(Score: 2) by hendrikboom on Thursday May 21 2020, @08:09PM (5 children)
I just happen to have hardware in a box somewhere with, I believe 1 gibibyte of ECC memory.
Do I have a chance in the XFS league? I'm interested in high long-term reliability rather than performance. Performance would be nice, but preservation is priority.
(Score: 2) by hendrikboom on Thursday May 21 2020, @08:10PM
Whoops. Meant ZFS, not XFS. Damn people always pronouncing words like xerox as zerox.
(Score: 2) by TheRaven on Tuesday May 26 2020, @08:09AM (3 children)
There are some sysctls that let you tune the maximum size of the ARC. It's worth using them on a machine with a higher ratio of storage to RAM. If you're using it as a NAS and not using RAM for much apart from disk cache, you can leave them quite high, otherwise you may find you're swapping a lot because ARC is consuming all of your RAM and not leaving much for applications.
sudo mod me up
(Score: 2) by hendrikboom on Wednesday May 27 2020, @12:17AM (2 children)
Currently about 2TB on two 4TB disks, using ext4 on software RAID (just the two copies of everything RAID). Probably more later.
I'm trying to transition to keep my personal data in digital form instead of in paper books and vulnerable analog media.
Wanting to have a check-summed file system as a hedge against long-term undetected disk degeneration.
No need for deduplication.
There is a need for backups not to become corrupted by being backed up from a corrupted hard drive.
-- hendrik
(Score: 2) by TheRaven on Wednesday May 27 2020, @09:11AM (1 child)
If you make sure you tune the ARC sysctls, it should work with ZFS. Given that it's a read-mostly workload, you will see slowdown from the fragmentation but not much from the write amplification. That said, if the motherboard can fit more RAM, it's worth doing it. I have a NAS with 8GB of RAM because that's the most that the mini-ITX board will handle, but I'd be very tempted to bump it up to 32GB if the board would take it.
I'm using zfsbackup-go [github.com] for backups. It takes a snapshot and then uses zfs send to get the stream, chunks it, GPG encrypts it, compresses it, and sends it to cloud storage, so I can do incremental encrypted backups nice and easily.
sudo mod me up
(Score: 2) by hendrikboom on Wednesday May 27 2020, @12:50PM
Current situation:
That 1GB ECC system cannot take more RAM (and it's still in the box, unused).
I have an ancient machine with two GB of RAM. It's what I'm using now. It has a ten-year-old AMD processor, and does not have error-detecting RAM. Not reaally suitable for a file system that keeps rewriting data after transient residence in unreliable memory. (what's reliable over the course of a week or even a year isn't necessarily reliable over a decade)
I have a laptop with 16g of RAM. Hmmm. It can take two hard drives, though at present it has only one... a vague possibility? I think not, though it is my daily workhorse. Currently using one SSD, which I've heard is not the greatest for long-term data preservation. And the SSD is too small. Bulk files and critical files kept on the main server (the one with two GB of RAM) and accessed through sshfs. Some worries about file locking through sshfs; in particular, worries about simultaneous access to mbox files through a mail reader over sshfs and postfix, so I run my mail reader on the server over ssh -X. Frequently changed important files kept in distributed revision control (monotone, or, if to be publicly available, monotone *and* github)
Nor is something likely to be left at coffee shops by mistake or stolen when I have to visit the coffee shop lavatory the best place for long-term preservation of data. I'm not *that* worried about others having read access to these data. I am that worried about losing access to it myself.
Yes, I'll still need backups.
-- hendrik
Hmmm.... I could have a backup regime that checksums all files, writes the checksums to backup and complains if the file to be backed up has changed in the main file system without changing the last-updated time in the file system ... That would probably catch disk misreadings.
Data might then survive bit flips on disk.
Wouldn't need a new file system for this -- just a new backup program. And a very slow backup process, as it checksums every file on the hard drives.
-- hendrik