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

71–78 of 78 posts

Re: GEFS on OpenBSD: A Early Preview

#71

Post by kev009 »

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.

You can, to some degree, do an online defrag with zfs rewrite -P now although it is not the primary intent. The displayed fragementation may not go down or may even increase, but all the files will go through the allocation policy. zfs fragmentation display is a little misleading, it measures free space fragmentation.

Re: GEFS on OpenBSD: A Early Preview

#72

Post by creeperhost »

sellmesoap wrote: post #45
moody__ wrote: post #9

I've been following (and helping test) gefs on 9front for a while now. 9front's nightly builder has been running off of it for quite a while. Ori's done a fantastic job.

Oh my gosh, while I may have heard of 9front in passing I had a little look today and it's super cool! also shithub what an amazing alternative forge, it feels like one of those days when I'm part of the 10,000!

For reference, the shithub that plan9 uses is not shithub.sh (to any of my knowledge)

Re: GEFS on OpenBSD: A Early Preview

#73

Post by moody__ »

creeperhost wrote: post #72
sellmesoap wrote: post #45

Earlier quoted context omitted.

Oh my gosh, while I may have heard of 9front in passing I had a little look today and it's super cool! also shithub what an amazing alternative forge, it feels like one of those days when I'm part of the 10,000!

For reference, the shithub that plan9 uses is not shithub.sh (to any of my knowledge)

no they are different, our shithub is shithub.us to be specific.

Re: GEFS on OpenBSD: A Early Preview

#74

Post by scheme271 »

cestith wrote: post #70
LargoLasskhyfv wrote: post #68

Earlier quoted context omitted.

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 lo…

The recommendation is still to store metadata on a raid 1 or 1/0 partition and the data on a raid 5/6. Apparently there's still some issues with raid 5/6

Re: GEFS on OpenBSD: A Early Preview

#76

Post by throw0101a »

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…

> 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.

At this point in software/file system history, having some kind of TRIM functionality I think is pretty important: either built in, or a separate utility (like fstrim(8) for ext4, etc).

Are you planning to (eventually?) do a RAID (or at least mirror) layer, or will this strictly stick do file systems?

Re: GEFS on OpenBSD: A Early Preview

#77

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

#78

Post by throw0101a »

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?

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

Running ZFS since it was originally released on Solaris (June 2006) with zero problems (then FreeBSD, then Linux), including on RAID-5/6 (RAID-Z1/2) configurations, which btrfs still does not recommend using all these years later:

* https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...

What have the btrfs developer(s) been doing for the last decade(+) that the code is still of debatable dependability?

Post reply on HN