41–50 of 78 posts
* https://www.youtube.com/watch?v=juFndFy72gI
September 2026 EuroBSDCon presentation from Sunday:
* https://www.youtube.com/watch?v=yPoU4QEv_u8&t=49m43s
† BSD User Group
This is great timing considering I'm currently dealing with FFS corruption after my OpenBSD server lost power during a storm.
Are you sure it's not just a dodgy SSD that simply failed to persist data when losing power mid-write? I've had my share of sudden power cuts upon OpenBSD during the past 20+ years, and FFS has so far never gone corrupt on me.
Windows ran fine on the machine (Lenovo 200) before, and Linux ran fine after. FFS (and the intel video drivers) are the weakest part of OpenBSD in my experience, I liked many other aspects.
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.
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"
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.
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.
Earlier quoted context omitted.
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.
Fragmentation in ZFS wastes a lot of space. So it doesnt matter if it's SSD or not.
Earlier quoted context omitted.
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.
The day I can furnish my NAS in SSDs for roughly the same price as HDDs probably won't come before any current filesystem is obsoleted for some reason or another, methinks.