From Newsgroup: comp.misc

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

Linux has a rCLufsrCY 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 rCL5xbsdrCY option seemed to work, but I only needed to mount it read-only anyway, I wasnrCOt 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 DrCOOliveiro 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 donrCOt know what you mean by rCLproprietaryrCY, 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.

ThatrCOs 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 rCLone size fits allrCY when it came to filesystem design
-- they tended not to offer a choice of filesystems. And the BSDs
followed this.

Except somehow it became rCLone size fits all installations of the same
BSD variant, and nothing elserCY.
--- 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 donrCOt 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 DrCOOliveiro <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 DrCOOliveiro:

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|f
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 itrCOs a very high-overhead filesystem. Not sure yourCOd 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 DrCOOliveiro:

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

ZFS should be compatible ...

Yes, but itrCOs a very high-overhead filesystem. Not sure yourCOd 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|f
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|f
Marco

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

From Newsgroup: comp.misc

On Fri, 19 Jun 2026 13:35:58 +0100, Geoff Clare 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.

The BSD disease strikes again ...
--- 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 rCo description of ZFS pool features

DESCRIPTION
ZFS pool on-disk format versions are specified via rCLfeaturesrCY 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 anrCE 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 enrCE 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 rCy:rCO
(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

From Newsgroup: comp.misc

On 2026-06-07, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

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 donrCOt 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.

You are wrong there. With GNU/Linux it's always the same kernel.
Every BSD has a different userland *and* kernel.
They are different *operating systems* alltogether.
On 'disciplined changes', good luck when bcachefs or btrfs hit mainline.
I remind you all AX25 support has been axed away because of
'mah security'.
Meanwhile OpenBSD for instance still supports old FS', protocols
and whatnot. Even plain X, FVWM, CWM and NetBSD still supports
*old* and *weird* non-PC video cards just because with NetBSD
you can have a 'backup computer' anywhere, even with older consoles.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Wed, 1 Jul 2026 10:07:22 -0000 (UTC), Anthk GM wrote:

On 2026-06-07, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

And yet Linux can manage more disciplined changes that donrCOt 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.

You are wrong there. With GNU/Linux it's always the same kernel.
Every BSD has a different userland *and* kernel. They are different *operating systems* alltogether.

You are not refuting what I said, you are merely reinforcing my
point.

And all those different BSD variations are basically still addressing
the same sorts of applications -- desktop/workstation/server. Whereas
the single Linux kernel has found application in a much wider variety
of areas, like handheld and embedded devices, for example. Same
kernel. Same compatibility. No fragmentation.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

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

And all those different BSD variations are basically still addressing
the same sorts of applications -- desktop/workstation/server. Whereas
the single Linux kernel has found application in a much wider variety
of areas, like handheld and embedded devices, for example. Same
kernel. Same compatibility. No fragmentation.

BSDs definitely do embedded applications too. Apple have even used
NetBSD to run their Time Capsule devices:

https://www.osnews.com/story/144845/apple-wants-to-kill-your-time-capsule-but-they-run-netbsd-so-they-cant/

In the case of NetBSD, they support lots of obscure embedded
platforms which Linux doesn't (or doesn't want to anymore). Yet
the other BSDs can add their own features without needing to
support them on that many platforms, since they're not all part of
the same project. So I see some real up-sides to the BSD
fragmentation really.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2