Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #244651 > unrolled thread

btfs disk compatibility between i386 and amd64

Back to article view | Back to linux.debian.user

Contents

  btfs disk compatibility between i386 and amd64 Joseph Brenner <doomvox@gmail.com> - 2022-01-27 03:00 +0100
    Re: btfs disk compatibility between i386 and amd64 Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-28 17:40 +0100
      Re: btfs disk compatibility between i386 and amd64 Joseph Brenner <doomvox@gmail.com> - 2022-01-29 03:10 +0100
        Re: btfs disk compatibility between i386 and amd64 Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-29 11:10 +0100

#244651 — btfs disk compatibility between i386 and amd64

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.

[toc] | [next] | [standalone]

#244733

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#244758

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



On 1/28/22, Andrei POPESCU <andreimpopescu@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.
>
> 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
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to doom+unsubscribe@kzsu.stanford.edu.
>

[toc] | [prev] | [next] | [standalone]

#244761

[Multipart message — attachments visible in raw view] — view raw

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 <andreimpopescu@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?

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web