Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
1–10 of 65 posts
Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
#2Nice 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 positive, third-party evaluations of muxfs.
> This is where you can help.
> I need volunteers to test muxfs, provide feedback, and periodically publish test results.
Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
#3i can't find "zfs" mentioned once in this guy's doc so my first question is... why not?
Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
#4> a filesystem should automatically check and repair data as it is accessed rather than processing the entire filesystem tree upon every check or repair job.
Except this is not sufficient. Flash storage for example is especially susceptible to random bitrot of data over time regardless of whether or not it is ever accessed or even powered on. Ever tried to plug in an old USB stick or SD card only to find out it was totally busted or unreadable? Scanning the entire filesystem and re-checksumming everything is therefore completely necessary.
Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
#5i can't find "zfs" mentioned once in this guy's doc so my first question is... why not?
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.
Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
#6i 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 serve different use-cases.
Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
#7i can't find "zfs" mentioned once in this guy's doc so my first question is... why not?
Same reason he doesn’t mention BtrFS and a bunch of other file systems: Because he’s running OpenBSD which doesn’t support ZFS.
Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
#8i can't find "zfs" mentioned once in this guy's doc so my first question is... why not?
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.
Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
#9I 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, or anything that doesn't have stable inodes.)
(2) (Based on my reading of the article) it doesn't seem to hold a "log" or "sequence" to identify which of the two mirrors are ahead or if they are in sync. In case of a disconnect / reconnect you need to manually tell `muxfs` which is the "newer" one (by using a `sync` before being able to mount it).
(I haven't tested it though, I'm running Linux, but I'm quite interested because just last week I thought "why doesn't one implement a FUSE file-system to add checksums and thus prevent bitrot". `muxfs` also adds mirroring.)
Re: Muxfs – a mirroring, checksumming, and self-healing filesystem layer for OpenBSD
#10> a filesystem should automatically check and repair data as it is accessed rather than processing the entire filesystem tree upon every check or repair job. Except this is not sufficient. Flash storage for example is especially susceptible to random bitrot of data over time regardless of whether or not it is ever accessed or even powered on. Ever tried to plug in an old USB stick or SD card only to find out it was t…
There is the muxfs audit subcommand though that does that. I guess the author was trying to say that it shouldn't be the only way to do it, as that opens the door for silently returning corrupted data in-between runs, so you start pondering how low you should set the interval between audit runs etc. I guess with automatic checks on every access you can feel safe running the audit every other month or so.