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?