Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

sdadams.org

Post reply on HN
Print view View original

11–20 of 65 posts

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#11

Post by swinglock »

ciprian_craciun wrote: post #6
ikiris wrote: post #3

i can't find "zfs" mentioned once in this guy's doc so my first question is... why not?

Because ZFS is not supported on OpenBSD. In fact he does mention in the beginning of the article that he was surprised that none of the NAS related file-systems are not supported by OpenBSD. On the other side, ZFS is an overly complicated behemoth, that wants direct access to the block device. Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. So both serv…

Non ZFS filesystems are overly simplified, ignoring the problems they ought to be solving.

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#12

Post by nix23 »

hestefisk wrote: post #8
danielparks wrote: post #5

Earlier quoted context omitted.

From the page: > I decided it was finally time to build a file server to centralize my files and guard them against bit-rot. Although I would have preferred to use OpenBSD due to its straightforward configuration and sane defaults, I was surprised to find that none of the typical NAS filesystems were supported. OpenBSD does not support ZFS.

Theo is, perhaps rightfully so, against importing what is effectively a paravirtualized Solaris kernel into the OpenBSD source code in order to run a file system.

Too sad, because the partitioning of OpenBSD is why i don't use it, with ZFS you could just do a dataset throw x^w,nosuid etc on them and give them a quota, with ffs one can bet that you run out of space (earlier or later), in one of the partitions (Workstation NOT Server).

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#13

Post by arghwhat »

swinglock wrote: post #11
ciprian_craciun wrote: post #6

Earlier quoted context omitted.

Because ZFS is not supported on OpenBSD. In fact he does mention in the beginning of the article that he was surprised that none of the NAS related file-systems are not supported by OpenBSD. On the other side, ZFS is an overly complicated behemoth, that wants direct access to the block device. Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. So both serv…

Non ZFS filesystems are overly simplified, ignoring the problems they ought to be solving.

ZFS is not the simplest solution to the problems that "ought to be solved", and the implementation can be rather annoying - lacking support for hardware configuration changes, using its own cache system sidestepping the one in the kernel, and generally not fitting in with normal filesystem paradigms. And that's not even addressing that incremental sends - a huge feature - was (is?) broken due to holebirth, making it unreliable.

btrfs kinda blew up, but it would be nice to have a good and simple reliable filesystem that actually fits in with the others. ZFS is what we're stuck with till then.

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#14

Post by nix23 »

ciprian_craciun wrote: post #6
ikiris wrote: post #3

i can't find "zfs" mentioned once in this guy's doc so my first question is... why not?

Because ZFS is not supported on OpenBSD. In fact he does mention in the beginning of the article that he was surprised that none of the NAS related file-systems are not supported by OpenBSD. On the other side, ZFS is an overly complicated behemoth, that wants direct access to the block device. Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. So both serv…

>On the other side, ZFS is an overly complicated behemoth, that wants direct access to the block device. Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. So both serve different use-cases.

Na...it's not overly complicated for what it is, but yes it is a behemoth.

>that wants direct access to the block device.

Yes for high-performance "enterprise"-setup's it is preferable, but absolutely not needed.

> Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums.

That i think is the winning point here, just add bit-rot protection to ffs.

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#15

Post by swinglock »

arghwhat wrote: post #13
swinglock wrote: post #11

Earlier quoted context omitted.

Non ZFS filesystems are overly simplified, ignoring the problems they ought to be solving.

ZFS is not the simplest solution to the problems that "ought to be solved", and the implementation can be rather annoying - lacking support for hardware configuration changes, using its own cache system sidestepping the one in the kernel, and generally not fitting in with normal filesystem paradigms. And that's not even addressing that incremental sends - a huge feature - was (is?) broken due to holebirth, making it…

Some of them are grounded in Linux politics. I have hope in bcachefs but best not rush, we've all seen btrfs.

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#16

Post by magicalhippo »

ciprian_craciun wrote: post #6
ikiris wrote: post #3

i can't find "zfs" mentioned once in this guy's doc so my first question is... why not?

Because ZFS is not supported on OpenBSD. In fact he does mention in the beginning of the article that he was surprised that none of the NAS related file-systems are not supported by OpenBSD. On the other side, ZFS is an overly complicated behemoth, that wants direct access to the block device. Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. So both serv…

> that wants direct access to the block device

You can set up a ZFS pool backed by files[1]. Probably not something you should do with data you really care about, but it's possible.

[1]: https://linux.die.net/man/8/zpool (Virtual Devices)

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#17

Post by zasdffaa »

defrost wrote: post #2

Nice concept, and having skimmed it's worth noting: > muxfs needs you! > No filesystem can be considered stable without thorough testing and muxfs is no exception. > Even if I had tested muxfs enough to call it stable it still would not be responsible to expect you to simply take my word for it. It is for this reason that I do not intend to release a version 1.0 until there are sufficient citations that I can make to…

These requirements of much testing of inherently multithreaded code with a lot riding on not destroying user data suggests a model checker would be an essential piece, perhaps someone more knowledgeable can opine.

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#18

Post by hestefisk »

nix23 wrote: post #12
hestefisk wrote: post #8

Earlier quoted context omitted.

Theo is, perhaps rightfully so, against importing what is effectively a paravirtualized Solaris kernel into the OpenBSD source code in order to run a file system.

Too sad, because the partitioning of OpenBSD is why i don't use it, with ZFS you could just do a dataset throw x^w,nosuid etc on them and give them a quota, with ffs one can bet that you run out of space (earlier or later), in one of the partitions (Workstation NOT Server).

You can use your own partitioning though? One for /, one for swap. Done.

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#19

Post by anthk »

nix23 wrote: post #12
hestefisk wrote: post #8

Earlier quoted context omitted.

Theo is, perhaps rightfully so, against importing what is effectively a paravirtualized Solaris kernel into the OpenBSD source code in order to run a file system.

Too sad, because the partitioning of OpenBSD is why i don't use it, with ZFS you could just do a dataset throw x^w,nosuid etc on them and give them a quota, with ffs one can bet that you run out of space (earlier or later), in one of the partitions (Workstation NOT Server).

I doubt it. Even for ports you can still symlink /usr/ports to $HOME/ports, for Scummvm with --enable-all-engines or Eduke32 (Build/GPLv2 license clash, can't be shared as a binary).

/usr/local is not small at all by default.

Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD

#20

Post by nix23 »

hestefisk wrote: post #18
nix23 wrote: post #12

Earlier quoted context omitted.

Too sad, because the partitioning of OpenBSD is why i don't use it, with ZFS you could just do a dataset throw x^w,nosuid etc on them and give them a quota, with ffs one can bet that you run out of space (earlier or later), in one of the partitions (Workstation NOT Server).

You can use your own partitioning though? One for /, one for swap. Done.

Yes you can but you cant set stuff lime nosuid etc on /
Post reply on HN