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

21–30 of 78 posts

Re: GEFS on OpenBSD: A Early Preview

#21

Post by mmooss »

yjftsjthsd-h wrote: post #10

From https://orib.dev/gefs.pdf - > While snapshot consistency is useful to keep data consistent, disks often fail over time. In order to detect corruption, block pointers contain a hash of the data that they point at. If corrupted data is returned by the underlying storage medium, this is detected via block hashes. And if a programmer error causes the file system to write garbage to disk, this can often be caught ear…

I've always wondered about similar designs: Doesn't calculating a hash of every block, on every read and every write, create lots of overhead? Why isn't that a problem?

Some systems have dedicated crypto co-processors for confidentiality (encryption) - e.g., I think drives with FDE, and I think Apple Silicon SoCs might have them. Can those be repurposed for hash calculation? What about systems that lack them?

Re: GEFS on OpenBSD: A Early Preview

#22

Post by kjs3 »

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.

If we're looking at 'future' filesystems, is fragmentation really an issue in an SSD world? Not that there isn't a lot of spinning rust (and will be for quite a while), I don't think it's unreasonable to assume "most block storage is going to be SSD in the future" when allocating resources to priorities.

Re: GEFS on OpenBSD: A Early Preview

#23

Post by yjftsjthsd-h »

atmosx wrote: post #14
yjftsjthsd-h wrote: post #10

From https://orib.dev/gefs.pdf - > While snapshot consistency is useful to keep data consistent, disks often fail over time. In order to detect corruption, block pointers contain a hash of the data that they point at. If corrupted data is returned by the underlying storage medium, this is detected via block hashes. And if a programmer error causes the file system to write garbage to disk, this can often be caught ear…

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.

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.

Re: GEFS on OpenBSD: A Early Preview

#24

Post by chasil »

mmooss wrote: post #21
yjftsjthsd-h wrote: post #10

From https://orib.dev/gefs.pdf - > While snapshot consistency is useful to keep data consistent, disks often fail over time. In order to detect corruption, block pointers contain a hash of the data that they point at. If corrupted data is returned by the underlying storage medium, this is detected via block hashes. And if a programmer error causes the file system to write garbage to disk, this can often be caught ear…

I've always wondered about similar designs: Doesn't calculating a hash of every block, on every read and every write, create lots of overhead? Why isn't that a problem? Some systems have dedicated crypto co-processors for confidentiality (encryption) - e.g., I think drives with FDE, and I think Apple Silicon SoCs might have them. Can those be repurposed for hash calculation? What about systems that lack them?

Both ZFS and modern btrfs support a large set of checksums.

Both implement sha256, which does impose a heavy speed penalty.

ZFS allows you to adjust the checksum on the fly, using something faster (Fletcher) if desired.

In btrfs, a global checksum is set at filesystem creation; xxhash is the best modern option.

There is a website: https://xxhash.com

Deduplication adds concerns for a strong hash free of collisions.

Re: GEFS on OpenBSD: A Early Preview

#25

Post by yjftsjthsd-h »

cyberpunk wrote: post #13
fn-mote wrote: post #11

Is there any chance of proving a filesystem is correct? Is this one simple enough that it won’t have bugs?? Given the issues with well-known filesystems like ZFS and BetterFS, why shouldn’t I expect data-losing bugs in this one?

What well known data-losing bugs are there in zfs? It can be slow, and resource hungry, but afaik it's about as safe as they come (and I've been using it in prod since solaris 10)

Its native encryption has something of a poor history

Re: GEFS on OpenBSD: A Early Preview

#26

Post by yjftsjthsd-h »

mmooss wrote: post #21
yjftsjthsd-h wrote: post #10

From https://orib.dev/gefs.pdf - > While snapshot consistency is useful to keep data consistent, disks often fail over time. In order to detect corruption, block pointers contain a hash of the data that they point at. If corrupted data is returned by the underlying storage medium, this is detected via block hashes. And if a programmer error causes the file system to write garbage to disk, this can often be caught ear…

I've always wondered about similar designs: Doesn't calculating a hash of every block, on every read and every write, create lots of overhead? Why isn't that a problem? Some systems have dedicated crypto co-processors for confidentiality (encryption) - e.g., I think drives with FDE, and I think Apple Silicon SoCs might have them. Can those be repurposed for hash calculation? What about systems that lack them?

Yes, it adds some overhead, but it's fine IME. Granted, it helps that compression can significantly speed up performance. (I was very confused the first time I saw ZFS reading data faster than its drives were physically capable of, because it turned out the CPU could decompress faster than the drives could read)

Re: GEFS on OpenBSD: A Early Preview

#27

Post by sippingabonedry »

yjftsjthsd-h wrote: post #23
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.

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 dropped btrfs after the second time it hosed my rootfs

btrfs fans use the "you're using it wrong" excuse a lot.

I recall a failure mode that activated when you fill the FS to 100% and their response was "you should never fill a filesystem to capacity"

Re: GEFS on OpenBSD: A Early Preview

#28

Post by whalesalad »

yjftsjthsd-h wrote: post #23
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.

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?

Re: GEFS on OpenBSD: A Early Preview

#29

Post by atmosx »

yjftsjthsd-h wrote: post #23
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.

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.

> Who said anything about storage servers?

I did.

> I'm using zfs [...]

ZFS is primarily used on single-storage appliances.

Re: GEFS on OpenBSD: A Early Preview

#30

Post by jeffrallen »

sippingabonedry wrote: post #27
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 dropped btrfs after the second time it hosed my rootfs btrfs fans use the "you're using it wrong" excuse a lot. I recall a failure mode that activated when you fill the FS to 100% and their response was "you should never fill a filesystem to capacity"

Otoh, good luck bringing a CoW filesystem back from 100%. Delete a file? Sure, let me just make a copy of all the metadata that was pointing at it using... the zero blocks I have left.

Tradeoffs are a bitch, bitch.

Post reply on HN