Other EXT4 wrong magic number mount error

[liendolucas]

Hi everyone,

I'm kind of shocked because I can't understand what the heck is going on after partitioning and formatting an external USB drive.

I have a Raspberry Pi 3 running "FreeBSD redstar.local 13.0-RELEASE FreeBSD 13.0-RELEASE" (I trimmed the output of `uname`).

I plug the USB external drive to the Raspberry Pi and create a new partition scheme GPT and then create a single EXT4 partition for the whole available space. I mount it in the same system (no errors BUT I didn't test to write to it, after mounting it and checking the size with `df` I assumed everything was ok). Then I unmount it and replug it in a Linux machine. Gets automatically detected and mounted. Start copying files. Unmount it. Reconnect the drive in the Raspberry Pi try to mount it with: `mount -t ext2fs /dev/da0p1 /home/mpd/music` and to my dismay I'm getting the following error: `ext2fs: da0: wrong magic number 0 (expected 0xef53)`. What on earth is going on? Because I once again plug the drive to the Linux machine and yeap, seems absolutely fine, all files there! The thing is that I've formatted the drive in the Raspberry Pi with FreeBSD, so does a simply `cp` in Linux alters magic numbers or I'm screwing things up in a very stupid way?

I've been a bit frustrated so far with filesystems. Previously I've tried ZFS but is impossible to run in a Raspberry Pi with 1Gb of RAM behind a NFS (I would say that I don't know the tricks that I need to apply to both ZFS and NFS to make this constrained setup work). Launching `musicpd` from another computer and trying to read the files instantly kills the Pi (I see ARC skyrocketing and literally bringing the whole thing down, not giving me the slightlest chance to do a thing). So I said ok, given the fact that I need more RAM to run ZFS properly I decided to reformat the drive to EXT4 because I still want to be able to plug it to a Linux machine just in any case.

Any clues as why this happens?

Thanks in advance,
Lucas.

 

[jordane3141]

Have you tried running UFS, one of the default options during the install options?

 

[liendolucas]

jordane3141 I don't quite understand what you're suggesting. What does the installation process have to do with what I'm experiencing? (FreeBSD on the RPi is installed by simply writing an image to an SD card, not a regular interactive PC installation) Why are you also suggesting to try UFS? My question is related to EXT4 interop between FreeBSD and Linux.

Update: I've decided to do exactly the same steps as described before with two minor modifications: Create an EXT3 partition, write a "test" directory to it. Go to Linux plug the drive, copy some files and get the drive back to FreeBSD. Now I'm able only to mount the drive through: `fuse-ext2 /dev/da0p1 /home/mpd/music` (when I try the same command as in the original post I get a `mount: /dev/da0p1: Device busy`) but when doing an `ls` the whole directory is empty! No "test" directory nor any files that were copied from Linux are present there, everything is gone or not visible to FreeBSD! At this point at least for my use case I'm going to declare EXT compatibility completely dead/broken. Would love to hear if anyone had similar experiences.

Lucas.

 

[ralphbsz]

I plug the USB external drive to the Raspberry Pi and create a new partition scheme GPT and then create a single EXT4 partition for the whole available space.

Please tell us more detail. How did you format the file system on the partition?

Hint: I would never trust non-native file systems, other than in read-only mode. If you want to create an ext<n> file system, do so on Linux.

and to my dismay I'm getting the following error: `ext2fs: da0: wrong magic number 0 (expected 0xef53)`.

What file system type did you actually create, ext2 or ext4? How did you format the file system? When you wrote to it from Linux, was it mounted as ext2 or ext4?

Create an EXT3 partition, write a "test" directory to it.

How?

Go to Linux plug the drive, copy some files and get the drive back to FreeBSD.

Did you unmount the file system after writing? When I say unmount, I mean: really unmount, not just quiesce?

The #1 source of problems with moving external disks between computers is: failure to unmount after writing. That's because only when a real unmount happens is data really sync'ed to the disk.

At this point at least for my use case I'm going to declare EXT compatibility completely dead/broken.

I'll give you two answers that at first may seem contradictory. First, the ext2/3/4 compatibility system in FreeBSD is not completely broken, and mostly works. You have some sort of self-inflicted injury here, and since you didn't post details, that is hard to debug.

On the other hand, as I repeat endlessly, I don't trust non-native file system implementations. Yes, FreeBSD has compatibility systems for ext<n> and XFS and several other file systems, but those are all dangerous, and I would not use if you need a production worthy system, or good data durability. Similarly, Linux has support for UFS/FFS and several other foreign file systems, and the same criticism applies. I think there are two good interchange mechanisms for moving whole disks between OSes, and they are FAT (a.k.a. the MS-DOS file system, because it's so simply and so well understood, it's hard to implement in a broken way), and ZFS between FreeBSD and Linux (if you are careful with enabling feature flags). For all other data movement, I would recommend not mounting a portable disk, but instead running a disk server using the native OS (typically in a small VM), and exporting the data via a modern network protocol (such as NFSv4 or CIFS).

 

[liendolucas]

ralphbsz Thanks for replying! I'll try to answer the questions reviewing the commands that I've executed in the Raspberry Pi:

> How did you format the file system on the partition?

This is what my history reports and I hope I didn't mess up:

gpart create -s GPT da0
gpart add -t linux-data da0
mkfs.ext4 /dev/da0p1

> When you wrote to it from Linux, was it mounted as ext2 or ext4?

I actually haven't checked at all because I wasn't expecting something like this to ever happen! So when my Ubuntu 20.04 mounted automatically I've assumed that everything was ok!

> How I created the filesystem when I tried EXT3:

The drive wasn't mounted of course, I run:

mkfs.ext3 /dev/da0p1

After this, I mounted the partition and issued a `mkdir test` in the mounted directory. Did an `ls`, saw the directory and unmounted the filesystem (on FreeBSD).

> Did you unmount the file system after writing? When I say unmount, I mean: really unmount, not just quiesce?

I do not know what you refer to "quiesce", but every single time I work with either FreeBSD, Linux and external drives I manually run `umount DEVICE` and re-check that the filesystem was effectively unmounted by running `mount` and verifying that is no longer mounted. I never unplug a drive "a la Windows" without manually unmounting it as I know the potential implications.

One weird thing that I forgot to mention is that for the EXT3 test I copied music to it, about ~700Mb (I simply run `cp -r ...`) and I could see that this space was being effectively taken into account when plugged the drive once again in FreeBSD and run `df`. When I saw this behavior I also immediately checked for error messages through `dmesg` and these are entries that I could see (again it doesn't look wrong to me):

da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <External USB3.0 0204> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 201703310007F
da0: 40.000MB/s transfers
da0: 305245MB (625142448 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

I hope that this information gives you a better insight and that I haven't done anything wrong/unusual. I do understand what you say about filesystems and moving them between OSes, but it seems that the other only option I'm left is just ZFS? As for the usage of the drive I was going to dedicate it for musicpd in read only mode through NFS in my local network. I know again that an external drive and USB is not the way to go, but just keep in mind that I had these (the Pi and the drive) collecting dust and decided to make use of them ;-) Obviously for anything else I wouldn't go with this setup...

About the flags on ZFS that you mentioned... I experienced that first hand when I created a zpool in FreeBSD and then Linux decided to "upgrade" those, then re-connected the drive in FreeBSD and it refused to import the pools as it didn't understand the flags that were upgraded by Linux. I understand that this is no longer an issue as both FreeBSD and Linux use the same ZFS codebase (when I run into this, this wasn't the case).

Thanks for your time.