On Mon 09-05-11 14:59:29, Christoph Anton Mitterer wrote: > On Mon, 2011-05-09 at 14:06 +0200, Jan Kara wrote: > > Actually, contents of the files should be generally OK > > because mkfs overwrites only inodes. So you have lost some files and > > directories but once you have a file, it should be OK. > This is really some good news!! :-) > Are you sure with that? And wouldn't mean, that inodes are always > located at the same block locations? Well, the block size is most likely the same (4 KB) in both the old and the new fs (unless you tinkered with it but I don't expect that). That defines size of a block group and thus position of inodes, bitmaps, etc. Another variable is a number of inodes (per group). If you have an old superblock you can compare the old and the new number of inodes and you can be sure. Otherwise you rely on whether the math in the mkfs with which you've originally created the fs is the same as the math in your current mkfs (and you didn't specify any special options regarding this)... Honza > > > It's not that I wanna blame others (I mean being stupid is my fault), but > > > e2fsprogs' mkfs is really missing a check whether any known > > > filesystem/partition type/container (luks, lvm, mdadm, etc.) is already on > > > device (and a -force switch),... IIRC xfsprogs already do this more or > > > less. > > Yes, that would be reasonable although it might break some people's > > scripts. But probably worth it anyway. > IMHO the breakage is really justified then :-) > > Especially as some of those scripts might actually do their own checks > for some filesystems, but perhaps completely forget about other > containter types (partitions, LUKS, mdadm, etc. etc.) > > > Cheers, > Chris. -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
