FUSE? [LWN.net]

FUSE?

Posted Aug 19, 2019 17:40 UTC (Mon) by mstapelberg (guest, #66308)
In reply to: FUSE? by arcivanov
Parent article: Stapelberg: distri: a Linux distribution to research fast package management

This is a proof-of-concept, and FUSE allowed much quicker iteration times than writing my own kernel module :)

In my day-to-day, I don’t actually notice a perceivable slow-down, so the current FUSE implementation quick enough to demonstrate what I wanted to show.

But yeah, moving the file system into the kernel would certainly be a step on the productionization checklist for this approach!

There is also an interesting paper which talks about moving only the hot paths of a FUSE file system into the kernel using eBPF: https://www.usenix.org/system/files/atc19-bijlani.pdf

to post comments

FUSE?

Posted Aug 19, 2019 18:31 UTC (Mon) by kloczek (guest, #6391) [Link] (9 responses)

> This is a proof-of-concept, and FUSE allowed much quicker iteration times than writing my own kernel module :)

This sounds even more terrifying.

FUSE?

Posted Aug 19, 2019 20:40 UTC (Mon) by Paf (subscriber, #91811) [Link] (8 responses)

... why? Loading and unloading a kernel module can be painful, the environment is less forgiving, and if you screw up, oops there goes the system so now you have to reboot. It's all really annoying for starting out with brand new stuff and just hacking away.

Speaking as someone who works as a file system dev for my day job, prototyping stuff in FUSE is common (almost standard) practice. It's a great idea.

And if distri is already getting great speed, which it sounds like it is, then clearly FUSE isn't the bottleneck, so maybe it's best to just keep using it.

FUSE?

Posted Aug 19, 2019 21:32 UTC (Mon) by kloczek (guest, #6391) [Link] (7 responses)

Package management should not be about loading and unloading kernel modules.

FUSE?

Posted Aug 19, 2019 21:39 UTC (Mon) by mstapelberg (guest, #66308) [Link]

It isn’t. But developing a package manager (or any software, really) benefits from quick iteration times.

FUSE?

Posted Aug 20, 2019 3:26 UTC (Tue) by Paf (subscriber, #91811) [Link] (5 responses)

It’s ... not about that? Though development *might require that*, since fast iteration requires reloading code. Additionally, that’s an argument *for* using FUSE, not against using it?

FUSE is usually easier to develop within and intrinsically safer in several ways. If it’s fast enough that it’s not the bottleneck, then *great*.

FUSE?

Posted Aug 20, 2019 6:13 UTC (Tue) by kloczek (guest, #6391) [Link] (4 responses)

So why some package management aspects needs to be done in kernel space?

FUSE?

Posted Aug 20, 2019 7:07 UTC (Tue) by edomaur (subscriber, #14520) [Link] (3 responses)

These are *filesystem* aspects, in fact, not package management per se. And the kind of directory fusion evoked by this project could very well benefits other projects, like, for example, Docker-like systems, read only application deployment, immutable systems.

FUSE?

Posted Aug 20, 2019 21:12 UTC (Tue) by kloczek (guest, #6391) [Link]

Why package management must be part of the file systems?

FUSE?

Posted Aug 20, 2019 21:14 UTC (Tue) by kloczek (guest, #6391) [Link] (1 responses)

A so it is docker problem not a package management.
Good to know.

FUSE?

Posted Aug 28, 2019 12:11 UTC (Wed) by nix (subscriber, #2304) [Link]

It's not a "problem", it's a useful new filesystem feature, which, like most filesystem features, has multiple potential use cases. It's no more "package management" or a "docker problem" than overlayfs is a "live CD problem".

I can easily see you in the 1960s complaining that nobody needs these newfangled "file" thingies and the need for them over proper hardwired partitions laid out at disk format time is a problem with these newfangled programs that want such ridiculous fripperies.