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

31–40 of 65 posts

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

#31

Post by sdadams »

adrian_b wrote: post #25
ciprian_craciun wrote: post #9

I have only two issues with the `muxfs` implementation as it stands: (1) (And the largest problem) is that it requires stable inodes in order to tie the checksums with the actual files. This means (and it's already stated in the article) you can't copy / move / overwrite any of the underlying files without losing the checksums. (Basically it also removes the possibility of accessing one of the mirrors via NFS, FUSE,…

I am also using checksums to detect bit-rot, but in order to tie them to the files they are stored in extended attributes of the files. Thus they do not depend on the inode numbers. OpenBSD also supports extended file attributes, so using them should be possible. Using extended attributes on Linux or FreeBSD requires a few precautions, because there are still various copying/movement/archiving CLI commands or GUI app…

OpenBSD removed support for extended attributes.

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

#32

Post by asdf123a »

fbhabbed wrote: post #27
arghwhat wrote: post #24

Earlier quoted context omitted.

ZFS was never any prettier on BSD either, so wouldn't blame Linux in that. But yes, bcachefs is somewhat interesting. Or maybe btrfs manages to clean up their act one day.

What's wrong with btrfs?

as with all things GPL, victim of FUD campaigns by corporate america.

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

#33

Post by detaro »

fbhabbed wrote: post #27
arghwhat wrote: post #24

Earlier quoted context omitted.

ZFS was never any prettier on BSD either, so wouldn't blame Linux in that. But yes, bcachefs is somewhat interesting. Or maybe btrfs manages to clean up their act one day.

What's wrong with btrfs?

The parity-based RAID levels still are officially not safe for production, and overall many people don't quite trust it in more complex setups due to past bugs.

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

#34

Post by masklinn »

arghwhat wrote: post #23
masklinn wrote: post #21

Earlier quoted context omitted.

> ZFS is not the simplest solution to the problems that "ought to be solved" What are simpler solutions to the problems that ought to be solved?

A CoW filesystem itself is not much more complicated than a plain filesystem. Or maybe a CoW softraid, with the filesystem existing at a different layer. ZFS has countless bonus tunables, several types of caching distinct from the kernel VFS cache, its own write logs and special devices, multiple levels of topology (datasets in a pool consisting of vdevs consisting of drives), deduplication, compression, etc. It is a…

You didn't answer the question. You can't claim that there are simpler solutions then not actually provide a simpler solution. Which handwaving is not.

> A CoW filesystem itself is not much more complicated than a plain filesystem.

And yet there isn't one out there, there's pretty much only ZFS and BTRFS, the latter having been in a state of almost-but-not-actually-working for over a decade now.

bcachefs is the only contender and it remains a single-developer effort with little mainlining progress in the last few years.

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

#36

Post by Beltalowda »

masklinn wrote: post #21
arghwhat wrote: post #13

Earlier quoted context omitted.

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…

> ZFS is not the simplest solution to the problems that "ought to be solved" What are simpler solutions to the problems that ought to be solved?

Depends what problems you're looking to solve; you don't need a CoW filesystem if you just want data integrity features for example, and you don't need data integrity features if you're just looking for something with quick and efficient snapshots.

ZFS tries to solve every filesystem problem and actually doesn't even do a terrible job at it, but it can be a bit of a beast due to its high complexity and that it doesn't integrate well with the rest of the system.

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

#37

Post by Beltalowda »

nix23 wrote: post #22
anthk wrote: post #19

Earlier quoted context omitted.

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.

Quoted post unavailable.

I think they're trying to say is you can just link stuff to $HOME if some filesystem runs out of space (not an endorsement of that view, just an explanation).

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

#38

Post by minusf »

sdadams wrote: post #31
adrian_b wrote: post #25

Earlier quoted context omitted.

I am also using checksums to detect bit-rot, but in order to tie them to the files they are stored in extended attributes of the files. Thus they do not depend on the inode numbers. OpenBSD also supports extended file attributes, so using them should be possible. Using extended attributes on Linux or FreeBSD requires a few precautions, because there are still various copying/movement/archiving CLI commands or GUI app…

OpenBSD removed support for extended attributes.

not a 1:1 equivalent of the "classic" extended attr but there are special flags on files.

https://man.openbsd.org/chflags

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

#39

Post by adrian_b »

sdadams wrote: post #31
adrian_b wrote: post #25

Earlier quoted context omitted.

I am also using checksums to detect bit-rot, but in order to tie them to the files they are stored in extended attributes of the files. Thus they do not depend on the inode numbers. OpenBSD also supports extended file attributes, so using them should be possible. Using extended attributes on Linux or FreeBSD requires a few precautions, because there are still various copying/movement/archiving CLI commands or GUI app…

OpenBSD removed support for extended attributes.

I suppose that this has been done to ensure less work for the OpenBSD maintainers, but I do not consider it as a wise decision.

Extended file attributes can be used to implement a large number of useful things, many of them enhancing security, e.g. access-control lists. However, IIRC OpenBSD has chosen to also not implement ACLs.

In any case regardless how useful or not useful extended file attributes are considered to be, deciding to not implement them in the main file system used by an operating system has the immediate consequence of disqualifying this operating system for the use on a file server (a.k.a. NAS), which is an application domain where the *BSD operating systems have been traditionally very good.

The reason is that whenever such a NAS would have Windows, Linux or FreeBSD clients, transiting any file through that NAS would potentially lose data.

In general, in the documentation of any file system, the lack of support for features like extended attributes or access-control lists must be displayed very prominently, to warn any potential users about the risk of data loss during copy operations (because the file copy commands are usually stupid enough to not inform the users whenever they are stripping file metadata, so such a loss may be discovered only when it is too late).

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

#40

Post by sdadams »

adrian_b wrote: post #39
sdadams wrote: post #31

Earlier quoted context omitted.

OpenBSD removed support for extended attributes.

I suppose that this has been done to ensure less work for the OpenBSD maintainers, but I do not consider it as a wise decision. Extended file attributes can be used to implement a large number of useful things, many of them enhancing security, e.g. access-control lists. However, IIRC OpenBSD has chosen to also not implement ACLs. In any case regardless how useful or not useful extended file attributes are considered…

In another project of mine I considered using extended attributes to tag files into categories. With extended attributes not being universally supported and easily overlooked the conclusion I came to was that I should store that information in a database file. I didn't want to one day lose my (manually assigned) tags to an erroneous move command.

Anything non-native to OpenBSD can still be stored in muxfs as an archive file. You would need to ensure to pass the right arguments to the archiver to preserve the attributes in this case.

Post reply on HN