Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

btfs disk compatibility between i386 and amd64

0 views
Skip to first unread message

Joseph Brenner

unread,
Jan 26, 2022, 9:00:06 PM1/26/22
to
I was wondering if the on-disk data format for btrfs is
compatible between the i386 and amd64 code bases--
e.g. would you expect to be able to swap data drives
between machines running either?

I've got an old i386 installation with /home in it's
own partition, and I'm wondering if I can expect to just
unlink /home and install a new amd64 version, and then link
in the home parition again.

Andrei POPESCU

unread,
Jan 28, 2022, 11:40:15 AM1/28/22
to
On Mi, 26 ian 22, 17:33:04, Joseph Brenner wrote:
> I was wondering if the on-disk data format for btrfs is
> compatible between the i386 and amd64 code bases--
> e.g. would you expect to be able to swap data drives
> between machines running either?

In general yes.

> I've got an old i386 installation with /home in it's
> own partition, and I'm wondering if I can expect to just
> unlink /home and install a new amd64 version, and then link
> in the home parition again.

Careful, unlink in the *nix world typically means delete (a file), while
you probably meant unmount / mount.


In general there shouldn't be a problem for newer kernels to read older
versions of a particular file system[1], but the other way around can be
a problem.

More than that, as far as I recall some newer kernels would
automatically enable some new features thus rendering the particular
file system unreadable for older kernels[2].

In any case, this should be very well documented for every file system,
so you should check the btrfs documentation for that.


[1] In this context I consider the various ext file systems to be
different file systems, not different versions of the same file system,
although they do have much more in common between them then with xfs or
so.

[2] I believe this was with ext4, but it could have been ext3

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc

Joseph Brenner

unread,
Jan 28, 2022, 9:10:05 PM1/28/22
to
> Careful, unlink in the *nix world typically means delete (a file), while
you probably meant unmount / mount.

Yes, precisely.


> In general there shouldn't be a problem for newer kernels to read older
versions of a particular file system[1], but the other way around can be
a problem.

That's interesting in itself. Makes some sense.

Thanks much.
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to doom+uns...@kzsu.stanford.edu.
>

Andrei POPESCU

unread,
Jan 29, 2022, 5:10:05 AM1/29/22
to
On Vi, 28 ian 22, 17:44:59, Joseph Brenner wrote:
> > Careful, unlink in the *nix world typically means delete (a file), while
> you probably meant unmount / mount.
>
> Yes, precisely.
>
>
> > In general there shouldn't be a problem for newer kernels to read older
> versions of a particular file system[1], but the other way around can be
> a problem.
>
> That's interesting in itself. Makes some sense.
>
> On 1/28/22, Andrei POPESCU <andreim...@gmail.com> wrote:
> > On Mi, 26 ian 22, 17:33:04, Joseph Brenner wrote:
> >> I was wondering if the on-disk data format for btrfs is
> >> compatible between the i386 and amd64 code bases--
> >> e.g. would you expect to be able to swap data drives
> >> between machines running either?
> >
> > In general yes.
> >
> >> I've got an old i386 installation with /home in it's
> >> own partition, and I'm wondering if I can expect to just
> >> unlink /home and install a new amd64 version, and then link
> >> in the home parition again.

Later I realised my answer doesn't directly address your query regarding
i386 (32 bits) -> amd64 (64 bits).

In general I would expect a 64 bit kernel (could also be arm64) to be
able to deal with a file system created by a 32 bit kernel. In case
there are any limitations they are likely to appear the other way
around, e.g. a file system created on a 64 bit system *might* have some
internals that can't be dealt with by a 32 bit kernel. Again, such
limitations should be thoroughly documented.

In any case, just trying to mount the file system (read-only if you want
to be extra careful) with an eye on 'dmesg -w' should be enough. If
there are problems the kernel should simply refuse to mount it.

As with anything dealing with possibly irreplaceable data, you should
have good backups. Could you recover your data if you format and
overwrite the partition by mistake?
signature.asc
0 new messages