DragonFlyBSD's HAMMER2 File-System Being Ported to NetBSD | Hacker News Reader

DragonFlyBSD's HAMMER2 File-System Being Ported to NetBSD

phoronix.com

142 pointsnetworked44 comments

NetBSD always does interesting things that to me seems hard to do. Me, I am looking forward to v10 to replace another OS with that has a very hard hard time with that laptop.

I donated early this year after seeing how far away they were from their 2022 goal, which is very modest. I hope this news stores up their finances :)

I think the corresponding page is https://www.netbsd.org/donations/, which suggests they're hoping to raise $50k this year.

I’ve always felt BSDs are way underrated, and Dragonfly being underrated the most.

Dragonfly has some really innovative features:

- H2

- virtual kernels

- how it achieves SMP with no locking

- and much more

That's the kernel memory allocator in SMP being lockless, right? (https://www.dragonflybsd.org/features/) You still can't get around locks for many shared resources, especially hardware ones.

Linus Torvalds says that the RCU mechanism in the kernel making filesystem access lockless is one of the greatest achievements in Linux.

wow LWKT and HAMMER2 look good.

Too bad it's only x86(64)-compatible. Even port to ARMv8 (Raspberry Pi especially) could help to increase the interest to this OS.

Today, I'd instead look at 64bit RISC-V, as that's where computing seems to be going.

Really? Please show me a production server based on RISC-V, dont get me wrong i would love that, but reality being reality ARM is something atm..and not RISC-V...nor POWER...hmhmmm..

The first ones (e.g. based on Ventana's Veyron) are due H2 this year.

ARM has some cursory presence in the datacenter today, but I wouldn't bet on ARM being more predominant than RISC-V there by 2025.

If anything, migration of servers to ARM has halted because decision makers can read the writing on the wall.

>If anything, migration of servers to ARM has halted because decision makers can read the writing on the wall.

I see the opposite here...

>but I wouldn't bet on ARM being more predominant than RISC-V there by 2025.

Sure Apple and all Smartphones will change to RISC-V, look i would love to believe that, it's just not the reality. But if you talk about microcontroller'ish stuff, then you are probably right that risv will be more dominant in 2025.

> virtual kernels

I'm pretty sure that's equivalent to netbsd's rump kernels and Linux's UML (user mode Linux), no? Certainly a good feature, and something I were saw wider use, but hardly unique.

The NetBSD rumpkernel allows for running individual drivers in userspace, while UML and vkernel are both geared towards running full kernels. UML and vkernel both look pretty similar to me though.

That's true, but that just means that rump kernels took the microkernel approach and make you do it piecemeal; I still think it counts as a different side of the same coin.

FreeBSD Hammer2 [r/o][pending]

Lots of work will end up (as often) in the ports section, if nobody has a strong point why it is usefull to maintain it in base.

Users/use-cases feedback are welcome.

https://reviews.freebsd.org/D37354 https://github.com/freebsd/freebsd-src/pulls

Back in 2015 there was attempt to port Hammer2 to OpenBSD:

http://undeadly.org/cgi?action=article&sid=20150429080405&co...

It doesn't seem to have been finished:

https://github.com/bradla/OpenBSD-Hammer2

Anyone can enlighten where do usually netBSD and dragonflyBSD get deployed? What kind of usecase or who's high profile user?

NetBSD are mostly embeded systems.

and dragonfly don’t get deployed =)

edit: dragonflybsd is mostly a playground for those innovative ideas and features

The good old AirPort Extreme runs on NetBSD.

I believe Japanese ISP's used netBSD in their hardware. I think it's used in many embedded systems as another user pointed out. NASA has used NetBSD in the past as well.

https://netbsd.org/gallery/research.html#sams-ii

https://www.netbsd.org/gallery/products.html

Sega Dreamcast owners :) https://wiki.netbsd.org/ports/dreamcast/

I have a DEC Alpha sitting around I want to get NetBSD on along with a few others that could run it.

Try it! We have Alpha binary packages :)

https://zia.io/notice/ARclSIZzZKNlAfXoFE

At University

http://sdf.org

I used it. As Desktop, daily driver, and on servers. The same way I used Gentoo. The thing is, if you compile from source, and don't need proprietary apps which assume linuxisms, anything which is compiled from source runs just the same way, as it would under Linux, or even(slightly) better. But that seems to be an almost lost art, nowadays? (Assuming you have fully supported hardware, drivers, and such, which was the case for a while with some systems) Meanwhile they also have a package manager for binaries, but I've never used that because I've been used to using sources :-)

http://netbsd.org/docs/pkgsrc/using.html

( https://pkgsrc.se/ is like FreshPorts for FreeBSD )

However, I've got lazy, too, and now use some ready made distro booted from USB-keychain, running from RAM.

Besides that, what would be the usecase? The base system is small, lean & mean, and in my experience rock solid, as in UNKAPUTTBAR. The organization and style of source was more understandable to me, as was the framework to recompile the base via build.sh (make world in FreeBSD terminology), and applications from their 'Ports/Portage/AUR' which is called PKGSRC there.

The same goes for the filesystem layout, /etc, init, and so on. It's just really nice, all in all.

Thinking about it, the question is like what would be the usecase for Alpine-Linux? Some people are using that as desktop, too, for probably similar reasons, but enjoying better hardware driver support.

I think the highest hurdle for people has been the 'strange concept' of using 'slices' and 'BSD-Disklabels' to further split apart MBR-style partitions.

Like explained here: http://netbsd.org/docs/guide/en/chap-inst.html#chap-inst-ins... & https://en.wikipedia.org/wiki/BSD_disklabel

I don't know how that applies to UEFI/GPT-partitioning and secure-boot actually. Haven't tried that, so far. Seems to be another hurdle, though I know from others that it runs, at least without secure-boot. Seems to be that 'The Guide' and FAQs are lagging behind reality. As often is the case, need to read mailing lists then, sigh...

Or simply searching for UEFI and GPT on their wiki, which leads to:

https://wiki.netbsd.org/Installation_on_UEFI_systems/ & https://wiki.netbsd.org/users/spz/moderndisk/

Furthermore: different device names. And an INIT which is neither SysV, nor systemd.

http://www.mewburn.net/luke/talks/auug-2003/ & https://www.netbsd.org/docs/guide/en/chap-rc.html

Which wasn't even mentioned in all the (mainstream) discussions of SysV vs. systemd because NIH?

I don't know exactly how to say this, but IMO you've missed out on an experience, if you don't know it. No matter how inconvenient initial installation or hardware support is.

This belongs under your belt.

Well done to the NetBSD team. I haven’t used it for many moons, so maybe it’s time giving it a spin again.

yeah you should check it out. Hopefully NetBSD 10 will be out soon

Tried to use DragonFlyBSD as a desktop environment a couple of years ago, which turned out to be a disappointment. Haven't touched it since, did it get any better recently?

I asked the Oracle of Delphi and she told me that all your problems with DFly are a thing of the past.

Please touch it again.

BSDs are the slowest OSs by far on phoronix benchmarks. What’s so good about them?

I'm not sure being dismissive or judging from only one metric is big picture thinking. Some may even call it narrow mindedness.

A quick Google search would show many interesting aspects of the BSDs and especially NetBSD, from resource efficiency to keeping the "original" Unix alive on current hardware, but I suspect you may not the kind of person to be receptive to that.

It was an honest question, also having used all BSDs for a week each.

It was great to have one giant config file, a simple init, and the portstree being better than even the AUR.

However what stood out was lack of GPU acceleration, shady Bluetooth and Wi-Fi support, and overall slowness.

You should stop being so defensive.

> ...also having used all BSDs for a week each.

On bare metal, or virtualized?

> ...lack of GPU acceleration

Depends, for some older chipsets it was there, for me, then. Though I have to concur, that is annoying, when your's is much too new, and thus badly supported, if at all.

> ...shady Bluetooth and Wi-Fi support

I'm a caveman and really don't care about that. Not even under Linux :-)

> ...and overall slowness

Yes. That was unimpressive. But it went away after https://www.netbsd.org/docs/guide/en/chap-kernel.html and even more so after https://www.netbsd.org/docs/guide/en/chap-updating.html with https://pkgsrc.se/devel/cpuflags

( Could probably be done from elsewhere with https://www.netbsd.org/docs/guide/en/chap-build.html also, because cross-compiling is built in! )

Lastly applying some https://www.netbsd.org/docs/guide/en/chap-tuning.html#tuning...

That sounds all really complicated and time consuming, but at the times it wasn't. Because the base is smaller, the compilers were faster. Expecting it to perform out of the box without adapting it to the environment will lead to frustration.

It really can fly.

Some things I like about FreeBSD are its comprehensive documentation and its slow-but-steady pace of development. I find that it tends to have fewer features, but they are more solidly designed and less likely to change several times over a decade. Compare with Linux's rapid evolutions through hardware events frameworks (devfsd, hotplug, udev) or audio (alsa, oss, pulse) or systemd's ever-growing reach.

I feel I can keep up with FreeBSD, and have confidence that it won't change too much out from under me when I'm not looking.

That being said, it's not that different from a more stability-focused Linux distro like Debian.

Aside: here's an article about doing audio on FreeBSD, which also touches on some "why FreeBSD is nice in general" aspects, too: https://meka.rs/blog/2021/10/12/freebsd-audio/

phoronix is notoriously bad in benchmarks of BSD family. I don't know much about Net/Open/Drgonfly, but FreeBSD has very conservative settings by default, and Pgoronix never change defaults. FreeBSD can be tuned to be much faster for almost any Phoronix benchmark.

Care to share how?

It is complex topic. I'm using FreeBSD at server environment (you are right that Wifi and GPU support of FreeBSD is lagging, so I'm not using it on desktops/laptops).

As server, FreeBSD needs increasing all socket buffers via sysctls, tuning NIC IRQ moderation (depends on NIC, but we are not discussing Realtek ones here, am I right?), and, in the past, VFS caching and read-ahead was very conservative by default, but now ZFS is the same as on Linux (unfortunately, as some non-tunable Linux-induced optimizations slightly hurt performance on BSD, best ZFS performance were before switch to OpenZFS).

For example, "stock" FreeBSD 13 on my hand-built NAS (5x8Tb zraid, system on SSD, E3-1220v3, 32GB RAM, Intel 10G NIC) only can serve ~250MB/s over SMB (with same Samba as Linux uses, of course), and after tuning (socket buffers, NIC IRQ coalescing, etc) it serves 750-800MB/s from cache and 500MB/s from spinning rust (which is obvious limitation of HDDs, not OS).

Unfortunately, I don't know one coherent and modern FreeBSD performance tuning guides, but this guide [1] is mostly actual still, for network part.

[1] - https://calomel.org/freebsd_network_tuning.html

And optimizations for database (MySQL, PostgreSQL) tests are other can of worms, which includes tuning of recordsize of ZFS, ZFS ARC/ARC2L tuning, etc., I'm not qualified to advice here, as I'm using FreeBSD on network devices (gateways, firewalls, VPN endpoints) and storage boxes mostly.

It is not all about benchmarks. Benchmarks are just statistics. You know what Benjamin D'Israeli said about statistics, right?

"There are three kinds of lies: lies, damned lies, and statistics."

There are more important things than raw performance numbers.

How stable is the OS? That means over years, not hours.