41–50 of 65 posts
Other than lack of support for NAS file systems in OpenBSD, is there a reason not to use ZFS (in favor of another file system providing similar features)?
Earlier quoted context omitted.
Some of them are grounded in Linux politics. I have hope in bcachefs but best not rush, we've all seen btrfs.
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.
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?
Earlier quoted context omitted.
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…
I think the complaints levelled against ZFS is a little unfair though. I agree that there are more elegant ways to implement ZFS but actually what we have already works really damn well. And the comments about the CLI being hard to use is weird because having used a hell of a lot of different file systems over the years (including BtrFS), I’ve found ZFS to be remarkably easy.
ZFS has saved me from a number of hardware failures. If it really were as bad as the comments on here have made out, it’s have lost data several times over.
Earlier quoted context omitted.
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 archi…
However, when instead of being compiled from sources, precompiled binaries are used, one must verify if the support for extended attributes has not been disabled, as it may happen in some misguided Linux distributions.
Besides such precompiled binaries where the xattr support had been disabled, I have also seen various GUI-based file managers that lacked support for xattr and which could strip them during copy or move operations.
The older tar and cpio archive formats do not support extended attributes, and many older tar programs support xattr, but by using tar or pax format extensions that may be incompatible with other tar implementations.
While it is important to be aware of these caveats, otherwise you may have unpleasant surprises, like I had many years ago, when I was copying files between different users via /tmp, and I could not understand where the files were losing metadata (and also their timestamps were truncated), until realizing that /tmp was on tmpfs, and copying to /tmp was silently stripping the extended attributes and truncating the timestamps (the latter might no longer be true today), with a few precautions it is possible to use extended attributes without problems on Linux and FreeBSD.
Before using extended attributes, I had also used a database file, but that had the disadvantage of being updated continuously all the time, even for file operations that did not change the file content, e.g. when renaming or moving files.
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 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…
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?
There were RFCs on proposals to address both the write hole and quota issues on LWN this year, with the write hole fix already having draft patches see "raid tree".
BTRFS is fine if you are not doing things that can hit those edges.
would porting ZFS have been worthwile? I know the CDDL is likely considered toxic to have in the kernel but even in a FUSE way might be worthwhile here, no?