From Newsgroup: comp.misc

One big issue with the BSD variants is that their filesystems are not
even compatible.

Linux has a “ufs” filesystem driver which tries to be compatible with
many of them (and even with proprietary Unixes like SunOS, HP/UX and
NextStep). I tried using it on a FreeBSD volume yesterday, and got
these lines in my dmesg:

[Fri Jun 5 13:54:57 2026] ufs: You didn't specify the type of your ufs filesystem

mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...

>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
[Fri Jun 5 13:54:57 2026] ufs: ufs_fill_super(): bad magic number

So the “5xbsd” option seemed to work, but I only needed to mount it read-only anyway, I wasn’t going to risk actually writing to it ...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:

One big issue with the BSD variants is that their filesystems are not
even compatible.

Not sure what you mean. The FFS has evolved over the years but most of
the BSD variants today use the same type.

Remember ext started out as a proprietary thing, and it's not completely
like normal Unix filesystems.

And yes, Linux can deal with that using the 5xbsd driver under FUSE which
is slow as hell but serviceable.

If you prefer, and many do, you can use xfs.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

One big issue with the BSD variants is that their filesystems are not
even compatible.

They are separate Operating Systems, unlike Linux distros
which all use the same kernel. So as years went on, some
divergences happened.

Linux has a ?ufs? filesystem driver which tries to be compatible with
many of them (and even with proprietary Unixes like SunOS, HP/UX and NextStep). I tried using it on a FreeBSD volume yesterday, and got
these lines in my dmesg:

<snip>

WARNING<<< Wrong ufstype may corrupt your filesystem,

default is ufstype=old

So the ?5xbsd? option seemed to work, but I only needed to mount it
read-only anyway, I wasn?t going to risk actually writing to it ...

I no longer have a FreeBSD system, but IIRC Linux never supported
write on ufs, also I think FreeBSD moved on to ufs2. Maybe that
is causing you the issues.
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

John McCue <jmclnx@gmail.com.invalid> wrote:

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

One big issue with the BSD variants is that their filesystems are not
even compatible.

They are separate Operating Systems, unlike Linux distros
which all use the same kernel. So as years went on, some
divergences happened.

AIUI the idea of taking a disc from one system to another was a foreign
concept at the time these FSes were developed. Discs being large heavy
things you kept in your rack with their own controllers, why would you try
to attach one to a different kind of system? That meant things like
structures and endianness were just whatever the host system happened to be
- there wasn't the idea of serialising to an on-disc format, you just dumped out your structs to disc and read them back next time you booted.

I no longer have a FreeBSD system, but IIRC Linux never supported
write on ufs, also I think FreeBSD moved on to ufs2. Maybe that
is causing you the issues.

That's my understanding too - I always used the ufs2 target to mount on
Linux. Seems that 5xbsd is a synonym for ufs2, being the FS in FreeBSD 5.x

https://docs.kernel.org/admin-guide/ufs.html
implies it's supported read-write.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 6 Jun 2026 09:46:17 -0400 (EDT), Scott Dorsey wrote:

On Sat, 6 Jun 2026 05:53:26 -0000 (UTC), Lawrence D’Oliveiro wrote:

One big issue with the BSD variants is that their filesystems are
not even compatible.

Not sure what you mean. The FFS has evolved over the years but most
of the BSD variants today use the same type.

If the Linux driver warns against corruption if choosing the wrong
variant, then presumably the same thing can happen among the BSDs
themselves: if one BSD variant tries to write to a filesystem created
by a different variant, then exactly the same sort of corruption can
occur.

Remember ext started out as a proprietary thing, and it's not
completely like normal Unix filesystems.

I don’t know what you mean by “proprietary”, since the exts were
always open-source. They have always supported full POSIX semantics.
There has never been any subtle format variation among different Linux
distros that could lead to corruption, unlike the BSDs.

And yes, Linux can deal with that using the 5xbsd driver under FUSE
which is slow as hell but serviceable.

This is a Linux kernel module.

If you prefer, and many do, you can use xfs.

That’s how the FreeBSD system was set up, I had no choice.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 06 Jun 2026 18:28:16 +0100 (BST), Theo wrote:

John McCue <jmclnx@gmail.com.invalid> wrote:

They are separate Operating Systems, unlike Linux distros which all
use the same kernel. So as years went on, some divergences
happened.

AIUI the idea of taking a disc from one system to another was a
foreign concept at the time these FSes were developed.

No, because all this divergence happened in the 1990s and onwards.

Discs being large heavy things you kept in your rack with their own controllers, why would you try to attach one to a different kind of
system?

Interesting you mention that. Proprietary platforms seemed to follow
the concept of “one size fits all” when it came to filesystem design
-- they tended not to offer a choice of filesystems. And the BSDs
followed this.

Except somehow it became “one size fits all installations of the same
BSD variant, and nothing else”.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Theo <theom+news@chiark.greenend.org.uk> wrote:

John McCue <jmclnx@gmail.com.invalid> wrote:

I no longer have a FreeBSD system, but IIRC Linux never supported
write on ufs, also I think FreeBSD moved on to ufs2. Maybe that
is causing you the issues.

That's my understanding too - I always used the ufs2 target to mount on Linux. Seems that 5xbsd is a synonym for ufs2, being the FS in FreeBSD 5.x

https://docs.kernel.org/admin-guide/ufs.html
implies it's supported read-write.

That implication might be misleading. The description for the
kernel config option to enable UFS contradicts it by explicitly
stating that UFS2 "is READ-ONLY supported". Although write support
for some UFS variants can be enabled with CONFIG_UFS_FS_WRITE which
is marked experimental/dangerous so Linux distros often don't
enable that even if they do build the UFS driver.

https://www.kernelconfig.io/CONFIG_UFS_FS?arch=x86&kernelversion=7.0 https://www.kernelconfig.io/CONFIG_UFS_FS_WRITE?arch=x86&kernelversion=7.0

So FreeBSD uses UFS2 while UFS(v1), used by default in other
active BSDs, has slightly better (but still weak) Linux support.
FreeBSD, NetBSD and OpenBSD all make UFS(v1) file systems which
work using the "44bsd" "ufstype" with the Linux driver.

Big deal. On the other side of the coin I once installed Linux
using Reiserfs 3 as the filesystem...

Also people who claim the BSDs have better documentation than Linux
could have a point. It doesn't take much to beat official docs that
don't agree on whether write support for a filesystem exists or
not.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Computer Nerd Kev <not@telling.you.invalid> wrote:

Also people who claim the BSDs have better documentation than Linux
could have a point. It doesn't take much to beat official docs that
don't agree on whether write support for a filesystem exists or
not.

The man pages for BSD have examples and are mostly coherent. But also,
BSD is not subject to the high rate of random change that linux is, and consequently the documentation tends to stay correct for longer.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 6 Jun 2026 21:00:40 -0400 (EDT), Scott Dorsey wrote:

The man pages for BSD have examples and are mostly coherent. But
also, BSD is not subject to the high rate of random change that
linux is, and consequently the documentation tends to stay correct
for longer.

And yet Linux can manage more disciplined changes that don’t do random
things like break filesystem compatibility. This is why you can have
300 different Linux distros that will interoperate more freely than
half a dozen BSD variants are able to manage.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Computer Nerd Kev <not@telling.you.invalid> wrote:
<snip>

So FreeBSD uses UFS2 while UFS(v1), used by default in other
active BSDs, has slightly better (but still weak) Linux support.

IIRC, NetBSD made changes to its file system in Release
10.0. So I do not know if its ffs2 is supported on Linux
either. This is what I quickly found on ffsv2.

https://wiki.netbsd.org/tutorials/acls_and_extended_attributes_on_ffs/

But, NetBSD also has zfs, though an older version. Maybe
zfs could work. But I never used ZFS on any system.


OpenBSD ffs was updated in 6.7, now it is ffs2. I do not
know if that is supported by Linux these days:

https://why-openbsd.rocks/fact/ffs2/
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Theo wrote:

AIUI the idea of taking a disc from one system to another was a foreign concept at the time these FSes were developed. Discs being large heavy things you kept in your rack with their own controllers, why would you try
to attach one to a different kind of system?

This is a good point and it highlights something about Linux that
people miss. The ext family wasn't designed by OS developers for
their own kernel -- it was designed by people who knew the
filesystem would run on wildly different hardware under wildly
different distros. That portability constraint was there from the
start because Linux never had a "our hardware, our way" luxury.

The BSDs had the opposite problem: they could assume a coherent
stack because the project controlled the whole thing. When they
diverged, nobody planned for cross-variant portability because
why would you? You ran FreeBSD or OpenBSD, not both.

What's funny is this mirrors the Linux-vs-BSD user experience
more broadly. Linux distros fragment at the userspace level
(packaging, init, desktop) but share a kernel. BSDs share a
philosophy but fragment at the system level. Pick your
fragmentation layer.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

One big issue with the BSD variants is that their filesystems are not
even compatible.

So is it Microsoft's NTFS in BSD land which is universal then?

Personally I've found NTFS the best choice between Windows, Linux,
Android phones and both Android-based and other random media players and
TVs.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Tue, 09 Jun 2026 11:25:37 +0300, Anssi Saari wrote:

Personally I've found NTFS the best choice between Windows, Linux,
Android phones and both Android-based and other random media players
and TVs.

Kind of a lowest-common-denominator, I guess. It it showing its age,
though: it has trouble dealing efficiently with lots of small files.

Remember that all those Android/Linux devices have inbuilt support for
the usual Linux filesystems. And there are probably more of them in
your house than Windows machines, nowadays.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Am 06.06.26 um 07:53 schrieb Lawrence D’Oliveiro:

One big issue with the BSD variants is that their filesystems are not
even compatible.

ZFS should be compatible - at least with Solaris and Linux (after
installation of the kernel module, as it is not included in the default kernel).
--
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Thu, 18 Jun 2026 21:44:24 +0200, Marco Moock wrote:

ZFS should be compatible ...

Yes, but it’s a very high-overhead filesystem. Not sure you’d want to
boot from it, for example.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Marco Moock wrote:

ZFS should be compatible - at least with Solaris and Linux

For "Solaris" variants derived from Open Solaris (i.e. systems
now built from the Illumos source), that should be true. However,
I think ZFS in actual Solaris (i.e. 11.4 from Oracle) might not
be compatible with BSD and Linux any more, as I seem to recall
reading that their ZFS and Open ZFS have diverged.
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Am 19.06.26 um 01:09 schrieb Lawrence D’Oliveiro:

On Thu, 18 Jun 2026 21:44:24 +0200, Marco Moock wrote:

ZFS should be compatible ...

Yes, but it’s a very high-overhead filesystem. Not sure you’d want to boot from it, for example.

That's the default for FreeBSD. Works fine. Although, they not yet
support booting from encrypted ZFS filesets. :-(
--
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Am 19.06.26 um 14:35 schrieb Geoff Clare:

Marco Moock wrote:

ZFS should be compatible - at least with Solaris and Linux

For "Solaris" variants derived from Open Solaris (i.e. systems
now built from the Illumos source), that should be true. However,
I think ZFS in actual Solaris (i.e. 11.4 from Oracle) might not
be compatible with BSD and Linux any more, as I seem to recall
reading that their ZFS and Open ZFS have diverged.

Changed by Oracle or OpenZFS?
--
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <1113nfh$3dsqm$2@dont-email.me>, Marco Moock <mm@dorfdsl.de> wrote: >Changed by Oracle or OpenZFS?

Both.

John
groenveld@acm.org
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Geoff Clare <geoff@clare.see-my-signature.invalid> wrote:

Marco Moock wrote:

ZFS should be compatible - at least with Solaris and Linux

For "Solaris" variants derived from Open Solaris (i.e. systems
now built from the Illumos source), that should be true. However,
I think ZFS in actual Solaris (i.e. 11.4 from Oracle) might not
be compatible with BSD and Linux any more, as I seem to recall
reading that their ZFS and Open ZFS have diverged.

ZFS has 'feature flags' to manage this. When you install an old disc in a
new machine, 'zpool status' asks if you want to upgrade your flags to the current version. If you upgrade you get access to more features but lose backward compatibility with the OS the disc was originally used with. If
you don't you retain backwards compatibility.

I believe the Illumos and OpenZFS people have different extensions
controlled by different sets of feature flags. So I think you can keep compatibility if you stick to a baseline set of features. The same applies when upgrading to a newer OpenZFS - if you allow new feature flags then you
can no longer use the disc with the older OpenZFS.


$ sudo zpool status pool

pool: pool
state: ONLINE
status: Some supported and requested features are not enabled on the pool.
The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not support
the features. See zpool-features(7) for details.


$ man zpool-features

ZPOOL-FEATURES(7) BSD Miscellaneous Information Manual

NAME
zpool-features — description of ZFS pool features

DESCRIPTION
ZFS pool on-disk format versions are specified via “features” which
replace the old on-disk format numbers (the last supported on-disk
format number is 28). To enable a feature on a pool use the zpool
upgrade, or set the feature@feature-name property to enabled. Please
also see the Compatibility feature sets section for information on how
sets of features may be enabled together.

The pool format does not affect file system version compatibility or
the ability to send file systems between pools.

Since most features can be enabled independently of each other, the
on-disk format of the pool is specified by the set of all features
marked as active on the pool. If the pool was created by an‐ other
software version this set may include unsupported features.

Identifying features

Every feature has a GUID of the form com.example:feature-name. The
reversed DNS name ensures that the feature's GUID is unique across all
ZFS implementations. When unsupported features are en‐ countered on a
pool they will be identified by their GUIDs. Refer to the
documentation for the ZFS implementation that created the pool for
information about those features.

Each supported feature also has a short name. By convention a
feature's short name is the portion of its GUID which follows the ‘:’
(i.e. com.example:feature-name would have the short name
feature-name), however a feature's short name may differ across ZFS
implementations if following the convention would result in name
conflicts.

[snip]
--- Synchronet 3.22a-Linux NewsLink 1.2