Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZFS 2.3 released with ZFS raidz expansion

github.com

Post reply on HN
Print view View original

201–210 of 331 posts

Re: ZFS 2.3 released with ZFS raidz expansion

#201

Post by koverstreet »

pdimitar wrote: post #142
koverstreet wrote: post #94

Earlier quoted context omitted.

Erasure coding is almost done; all that's missing is some of the device evacuate and reconstruct paths, and people have been testing it and giving positive feedback (especially w.r.t. performance). It most definitely does have fsck and has since the beginning, and it's a much more robust and dependable fsck than btrfs's. Scrub isn't quite done - I actually was going to have it ready for this upcoming merge window exc…

FYI: the main reason I gave up on bcachefs is that I can't use devices with native 16K blocks. Hope that's coming this year. I have a bunch of old HDDs and SSDs and I could very easily assemble a spare storage server with about 4TB capacity. Already tested bcachefs with most of the drives and it performed very well. Also lack of ability to reconstruct seems like another worrying omission.

I wasn't aware there were actual users needing bs > ps yet. Cool :)

That should be a completely trivial for bcachefs to support, it'll mostly just be a matter of finding or writing the tests.

Re: ZFS 2.3 released with ZFS raidz expansion

#202

Post by tjoff »

BSDobelix wrote: post #176
qwertox wrote: post #174

Earlier quoted context omitted.

NTFS has Volume Shadow Copy, which is "good enough" for private users if they want to create image backups while their system is running.

First of all, that's not a backup, that's a snapshot, and NO, that's not "good enough", tell your grandma that all her digitised pictures are gone because her hard drive exploded, or that one most important jpeg is now unwatchable because of bitrot. Just because someone is a private user doesn't mean that the data is less important, often it's quite the opposite, for example a family album vs your cloned git reposito…

... VSS is used to create backups. Re-read parent.

Re: ZFS 2.3 released with ZFS raidz expansion

#203

Post by koverstreet »

ryao wrote: post #101
koverstreet wrote: post #94

Earlier quoted context omitted.

Erasure coding is almost done; all that's missing is some of the device evacuate and reconstruct paths, and people have been testing it and giving positive feedback (especially w.r.t. performance). It most definitely does have fsck and has since the beginning, and it's a much more robust and dependable fsck than btrfs's. Scrub isn't quite done - I actually was going to have it ready for this upcoming merge window exc…

Hearing that it is missing some code for reconstruction makes it sound like it is missing something fairly important. The original purpose of parity RAID is to support reconstruction.

We can do reconstruct reads, what's missing is the code to rewrite missing blocks in a stripe after a drive dies.

In general, due to the scope of the project, I've been prioritizing the functionality that's needed to validate the design and the parts that are needed for getting the relationships between different components correct.

e.g. recently I've been doing a bunch of work on backpointers scalability, and that plus scrub are leading to more back and forth iteration on minor interactions with erasure coding.

So: erasure coding is complete enough to know that it works and for people to torture test it, but yes you shouldn't be running it in production yet (and it's explicitly marked as such). What's remaining is trivial but slightly tedious stuff that's outside the critical path of the rest of the design.

Some of the code I've been writing for scrub is turning out to also be what we want for reconstruct, so maybe we'll get there sooner rather than later...

Re: ZFS 2.3 released with ZFS raidz expansion

#204

Post by worthless-trash »

azalemeth wrote: post #96
lousken wrote: post #74

Earlier quoted context omitted.

as far as stability goes, btrfs is used by meta, synology and many others, so I wouldn't say it's not stable, but some features are lacking

My understanding is that single-disk btrfs is good, but raid is decidedly dodgy; https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5... states that: > The RAID56 feature provides striping and parity over several devices, same as the traditional RAID5/6. > There are some implementation and design deficiencies that make it unreliable for some corner cases and *the feature should not be used in production, only…

Licensing incompatibilities.

Re: ZFS 2.3 released with ZFS raidz expansion

#206

Post by amluto »

Sesse__ wrote: post #36
ryao wrote: post #34

Earlier quoted context omitted.

Doing this with the on disk data in a merkle tree is much harder than doing it on more conventional forms of storage. By the way, what does MD do when there is corrupt data on disk that makes it impossible to know what the correct reconstruction is during a reshape operation? ZFS will know what file was damaged and proceed with the undamaged parts. ZFS might even be able to repair the damaged data from ditto blocks.…

Well, then they made a design choice in their RAID implementation that made fairly reasonable things hard. I don't know what md does if the parity doesn't match up, no. (I've never ever had that happen, in more than 25 years of pretty heavy md use on various disks.)

I’ve experienced bit rot on md. It was not fun, and the tooling was of approximately no help recovering.

Re: ZFS 2.3 released with ZFS raidz expansion

#207

Post by BSDobelix »

tjoff wrote: post #202
BSDobelix wrote: post #176

Earlier quoted context omitted.

First of all, that's not a backup, that's a snapshot, and NO, that's not "good enough", tell your grandma that all her digitised pictures are gone because her hard drive exploded, or that one most important jpeg is now unwatchable because of bitrot. Just because someone is a private user doesn't mean that the data is less important, often it's quite the opposite, for example a family album vs your cloned git reposito…

... VSS is used to create backups. Re-read parent.

Not good enough, you can make 10000 backups of bitrotten data, if you don't have check-sums on your block (zfs) or files (restic) nothing can help you. That's the same integrity as to copy stuff on your thump-drive.

Re: ZFS 2.3 released with ZFS raidz expansion

#208

Post by Polizeiposaune »

yjftsjthsd-h wrote: post #165
wil421 wrote: post #77

Earlier quoted context omitted.

How many of us are using single disks on our laptops? I have a NAS and use all of the above but that doesn’t help people with single drive systems. Or help me understand why I would want it on my laptop.

If the single drive in your laptop corrupts data, you won't know. ZFS can't fix corruption without extra copies, but it's still useful to catch the problem and notify the user. Also snapshots are great regardless.

In some circumstances it can.

Every ZFS block pointer has room for 3 disk addresses; by default, the extras are used only for redundant metadata, but they can also be used for user data.

When you turn on ditto blocks for data (zfs set copies=2 rpool/foo), zfs can fix corruption even on single-drive systems at the cost of using double or triple the space. Note that (like compression), this only affects blocks written after the setting is in place, but (if you can pause writes to the filesystem) you can use zfs send|zfs recv to rewrite all blocks to ensure all blocks are redundant.

Re: ZFS 2.3 released with ZFS raidz expansion

#209

Post by ryao »

shepherdjerred wrote: post #205

How does ZFS compare to btrfs? I'm currently using btrfs for my home server, but I've had some strange troubles with it. I'm thinking about switching to ZFS, but I don't want to end up in the same situation.

I first tried btrfs 15 years ago with Linux 2.6.33-rc4 if I recall. It developed an unlinkable file within 3 days, so I stopped using it. Later, I found ZFS. It had a few less significant problems, but I was a CS student at the time and I thought I could fix them since they seemed minor in comparison to the issue I had with btrfs, so over the next 18 months, I solved all of the problems that it had that bothered me and sent the patches to be included in the then ZFSOnLinux repository. My effort helped make it production ready on Linux. I have used ZFS ever since and it has worked well for me.

If btrfs had been in better shape, I would have been a btrfs contributor. Unfortunately for btrfs, it not only was in bad shape back then, but other btrfs issues continued to bite me every time I tried it over the years for anything serious (e.g. frequent ENOSPC errors when there is still space). ZFS on the other hand just works. Myself and many others did a great deal of work to ensure it works well.

The main reason for the difference is that ZFS had a very solid foundation, which was achieved by having some fantastic regression testing facilities. It has a userland version that randomly exercises the code to find bugs before they occur in production and a test suite that is run on every proposed change to help shake out bugs.

ZFS also has more people reviewing proposed changes than other filesystems. The Btrfs developers will often state that there is a significant man power difference between the two file systems. I vaguely recall them claiming the difference was a factor of 6.

Anyway, few people who use ZFS regret it, so I think you will find you like it too.

Re: ZFS 2.3 released with ZFS raidz expansion

#210

Post by unsnap_biceps »

wkat4242 wrote: post #181
cesarb wrote: post #175

Earlier quoted context omitted.

> Btrfs [...] still doesn't match ZFS in features [...] Isn't the feature in question (array expansion) precisely one which btrfs already had for a long time? Does ZFS have the opposite feature (shrinking the array), which AFAIK btrfs also already had for a long time? (And there's one feature which is important to many, "being in the upstream Linux kernel", that ZFS most likely will never have.)

ZFS also had expansion for a long time but it was offline expansion. I don't know if btrfs has also had online for a long time? And shrinking no, that is a big missing feature in ZFS IMO. Understandable considering its heritage (large scale datacenters) but nevertheless an issue for home use. But raidz is rock-solid. Btrfs' raid is not.

Raidz wasn't able to be expanded in place before this. You were able to add to a pool that included a raidz vdev, but that raidz vdev was immutable.
Post reply on HN