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

GEFS on OpenBSD: A Early Preview

marc.info

Post reply on HN
Print view View original

61–70 of 78 posts

Re: GEFS on OpenBSD: A Early Preview

#61

Post by throw0101a »

oridb wrote: post #58
throw0101a wrote: post #37

Earlier quoted context omitted.

> It's got CoW, snapshots, and data checksums. Therefore, it's good enough to compete with ZFS while being way smaller and permissively licensed. Does it have a built-in RAID layer? Because if it doesn't, then it can't compete with ZFS in many use cases. For example, what does "data may then be recovered from […] RAID restoration" mean? With ZFS, if you have a (e.g.) mirrored/RAID-1 configuration, and you fetch some…

Author here: correct, it's currently on the user to deal with corrupted data. I'm not opposed to adding a RAID layer, but I also want to explore what adding trim-style feedback to a generic RAID layer may look like, so that different file systems could share the work. We'll see where things go.

> […] but I also want to explore what adding trim-style feedback to a generic RAID layer may look like […]

TRIM commands sent to the block layer would probably help with SSD/NVMe wear leveling, as well as thin-provisioning in virtualized environments.

And the lack of RAID is not a critique: if you're mostly interested in the file system layer that's fine, and a useful area to solve problems in. My comment was more towards the comparison to ZFS and its "rampant layering violation" [1] and some of the trade-offs that happen when you focus on more or fewer parts of the stack.

[1] https://web.archive.org/web/20070602005153/http://blogs.sun....

Unrelated: and since you're surfing the comments, with regards to your superblocks [1], you may wish to look into some of the lessons learned by ZFS; specifically see perhaps Allan Jude's "Large Label and Blockpointer-V2" from the 2025 OpenZFS Dev Summit: https://www.youtube.com/watch?v=3tqOBv8BmXI

[1] https://orib.dev/gefs.pdf § 9.1

Re: GEFS on OpenBSD: A Early Preview

#62

Post by [deleted] »

gucci-on-fleek wrote: post #36
whalesalad wrote: post #28

Earlier quoted context omitted.

I have been hearing noise recently that btrfs is risky and unstable but (knocks on wood) i've been running it for years now with zero issues. What am I missing?

btrfs is almost 20 years old now, so lots of people only used it back when it was newer and far buggier. In my experience, btrfs is actually more reliable than other filesystems due to its checksumming abilities, but when it does fail, it's much harder to fix than with other filesystems (which will often try to continue on even when stuff is broken).

[deleted]

Re: GEFS on OpenBSD: A Early Preview

#63

Post by oridb »

throw0101a wrote: post #61
oridb wrote: post #58

Earlier quoted context omitted.

Author here: correct, it's currently on the user to deal with corrupted data. I'm not opposed to adding a RAID layer, but I also want to explore what adding trim-style feedback to a generic RAID layer may look like, so that different file systems could share the work. We'll see where things go.

> […] but I also want to explore what adding trim-style feedback to a generic RAID layer may look like […] TRIM commands sent to the block layer would probably help with SSD/NVMe wear leveling, as well as thin-provisioning in virtualized environments. And the lack of RAID is not a critique: if you're mostly interested in the file system layer that's fine, and a useful area to solve problems in. My comment was more to…

I don't mean a literal trim command to the block device, but hints that get passed to the RAID layer to mark how blocks should be spread among the backing devices. I haven't put much thought into the details, but I suspect that there might not be so much information needed, so the RAID layer could be both generic and smart. It may not work out.

I'll probably be picking Allan's brain on a few things in the coming few months; amusingly, he mentioned doesn't use ZFS for ZFS development so that he can unload and reload the module, and he's interested in something that won't corrupt when he panics the kernel.

Re: GEFS on OpenBSD: A Early Preview

#64

Post by Woodi »

oridb wrote: post #63
throw0101a wrote: post #61

Earlier quoted context omitted.

> […] but I also want to explore what adding trim-style feedback to a generic RAID layer may look like […] TRIM commands sent to the block layer would probably help with SSD/NVMe wear leveling, as well as thin-provisioning in virtualized environments. And the lack of RAID is not a critique: if you're mostly interested in the file system layer that's fine, and a useful area to solve problems in. My comment was more to…

I don't mean a literal trim command to the block device, but hints that get passed to the RAID layer to mark how blocks should be spread among the backing devices. I haven't put much thought into the details, but I suspect that there might not be so much information needed, so the RAID layer could be both generic and smart. It may not work out. I'll probably be picking Allan's brain on a few things in the coming few…

Hi author :) Must say that 8k+ lines is a little bit annoying and uneasy to handle... But also bribgs a lot of hope and happiness :)

To the point:

- llm'ed or not, dasn't matter, just quality matter

- raid ? I know nothing about that but looks like pure hardware raid (if that exists), no "raid layers" at all and fs raid aware are three different animals. But adding something about raids will complicate things before "production ready" stability. Which, of course, we want ASAP ;)

- 8k+ seems easy to manage and bend so maybe key-value only partitions ?

- obviously wishlist is easy to construct (key-value storage, encryption, power off resistance, mail reading ;) ) so maybe some plugin system or at least guidelines for peoples before we will have repos of patches DWM-style ? :)

- that 5 second is clearly stated but a bit strange limit and obviously peoples will want to do something with that

- man give us producion readiness before you will be puched by some corporation, swamped with work and hidden from daylight, pls ? Pleas do not fall into Compiz trap...

- thank you :)

Re: GEFS on OpenBSD: A Early Preview

#65

Post by snvzz »

BoingBoomTschak wrote: post #19

What a wonderful surprise! The nearest thing seem to be modern (v5) XFS + dm-integrity, I'll have to see a comparison once it's stable enough. A thing ZFS suffers from is fragmentation (no way to defragment in-place nor preallocate so stuff like bittorrent doesn't play well with it), which it justifies with its CoW design, wonder if/how it mitigates the problem.

>modern (v5) XFS

Is still silly, for the same reasons Hans Reiser documented in an article about Reiser4's design.

e.g. its b-tree stores directories and small files in the same level of the tree, which makes directory operations bloated, while also hurting cache lines.

Fortunately, neither ZFS, Hammer2 or GEFS suffer from this.

Re: GEFS on OpenBSD: A Early Preview

#66

Post by scheme271 »

whalesalad wrote: post #28
yjftsjthsd-h wrote: post #23

Earlier quoted context omitted.

Who said anything about storage servers? I'm using zfs on laptops and desktops right now because I want data checksums and a filesystem that doesn't have a history of breaking horribly (I dropped btrfs after the second time it hosed my rootfs). Given the license issue with zfs - and in particular, the technical fallout like needing dkms - I'd be very pleased to replace it.

I have been hearing noise recently that btrfs is risky and unstable but (knocks on wood) i've been running it for years now with zero issues. What am I missing?

It still has an issue with getting stuck in a bad state if you let the free space drop too low (e.g. under 5% / 2GB). It might still be recoverable but it takes a lot of fiddling and work to do that.

Re: GEFS on OpenBSD: A Early Preview

#68

Post by LargoLasskhyfv »

gigatexal wrote: post #48
atmosx wrote: post #14

Earlier quoted context omitted.

I don't think it will compete with ZFS or BTRFS (e.g. I don't think ppl will use GEFS over ZFS or BTRFS for a storage server), but it's a modern, much needed FFS replacement.

It’ll replace brtfs if it gets ported. Almost anything is better than that pile of garbage.

Running it for more than two years now, without any hassles. On single SSDs though. But still, waddya even talkin about?

Re: GEFS on OpenBSD: A Early Preview

#69

Post by LargoLasskhyfv »

rzerowan wrote: post #54
limagnolia wrote: post #53

I've always wondered why HAMMER2 from DragonFlyBSD hasn't gotten more attention from other OSes?

I think its the way their kernel architecture has diverged to this point in time.Seeing as it depends on structures/primitives in DRagonfly that dont exist in the other BSDs. Making a port a bit of a challenge.

Some people have 'hammered' on it, to varying degrees:

https://github.com/kusumi/hammer2

https://github.com/jdmanring/linux_hammer2

Re: GEFS on OpenBSD: A Early Preview

#70

Post by cestith »

LargoLasskhyfv wrote: post #68
gigatexal wrote: post #48

Earlier quoted context omitted.

It’ll replace brtfs if it gets ported. Almost anything is better than that pile of garbage.

Running it for more than two years now, without any hassles. On single SSDs though. But still, waddya even talkin about?

When I last took a serious look at btrfs its RAID 5 and RAID 6 modes could lose a whole lot of data if a single drive crashed or if the system lost power during a write. That's not supposed to happen on a RAID system with a journal.

From what I understand single copy setups, RAID 1, and RAID 10 never had the same problem. It's left a bad taste for a lot of people though.

Very early ext4 versions also had some data loss or data corruption, but I never hear people dismiss it completely for that brief spot of its history. Maybe part of that is because it was around 17 years ago and it's been a reliable default OS for many years now.

Post reply on HN