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
Attachment:
signature.asc
Description: PGP signature