Hi, > Thanks. I finally had a look at these (sorry for delay). well, thank you for having a look at the thing. > If you run "file" on one of the dumps, it tells you: > > $ file disk1.raw > disk1.raw: Minix filesystem > > Which isn't expected. I would expect something like > $ file xxx > xxx: Linux rev 1.0 ext3 filesystem data, UUID=fe55fe6f-0412-4a0a-852d-a0e21767aa35 (needs journal recovery) (large files) > > for an ext3 filesystem. > > Looking at /usr/share/misc/magic, it seems that a Minix filesystem is defined > by: > 0x410 leshort 0x137f Minix filesystem > > i.e. the 2 bytes at 0x410 into the device are 0x137f, which exactly what we > find in your dump. > > 0x410 in an ext3 superblock is the lower bytes of "s_free_inodes_count", the > count of free inodes. > Your actual number is 14881663, which is 0x00E3137F. Ah! But this means there is a bug somewhere... > So if you just add or remove a file, the number of free inodes should change, > and your filesystem will no longer look like a Minix filesystem and > your problems should go away. Uhm, OK, I just re-created the MD and the FS, so I took also the opportunity to increase the chunk size to 512K and use RAID-10. > I guess libblkid et-al should do more sanity checks on the superblock before > deciding that it really belongs to some particular filesystem. So, should one of us file a bug report somewhere? I mean, it is not only (lib)blkid, but also "file" which seems to be confused. BTW, "file" does not seem to use libblkid. > But I'm happy - this clearly isn't a raid problem. That's certainly good news, thanks again for the explanation, I learned something today! bye, -- piergiorgio -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
