On Tue, 14 Dec 2004 00:14:44 GMT, Lily Tse said:
is lost), is there any way I can find out the exact cluster size for
FAT16, FAT32, NTFS, EXT2, and EXT3 volumes?
ext2/3 don't use clusters in the same sense as fat/ntfs do. They do have
the concept of a 'block group', but that's not the same idea.
If *all* copies of the superblock have been destroyed (see below), you can
probably still recover the values s_blocks_per_group, s_fragments_per_group,
and s_inodes_per_group by scanning the entire disk, finding where the things
that look like inodes are, and calculating the distance between the clumps of
inodes.
It's basically impossible to do this unless you get the source to fsck.ext3
and get your brain wrapped around it:
http://e2fsprogs.sourceforge.net/
That's probably easier to comprehend than trying to understand the code in
fs/ext2 and fs/ext3 directories of the Linux kernel, as those spend most of
their
time dealing with the order things happen in (stuff like doing proper locking
so if one process is doing a chmod() to change the permissions on a directory
at the same time another process is trying to unlink() a file in the same
directory, and o on), and e2fsprogs is *all* about the actual on-disk format..
Of course, if you've scrogged all the superblock copies, you're in trouble
anyhow.
Or as 'man mkfs.ext3' describes the -S flag:
-S Write superblock and group descriptors only. This is useful if
all of the superblock and backup superblocks are corrupted, and
a last-ditch recovery method is desired. It causes mke2fs to
reinitialize the superblock and group descriptors, while not
touching the inode table and the block and inode bitmaps. The
e2fsck program should be run immediately after this option is
used, and there is no guarantee that any data will be salvage-
able. It is critical to specify the correct filesystem block-
size when using this option, or there is no chance of recovery.
On a 650M filesystem, there were 2 backup superblocks created, and on a
6G filesystem, there were 7 scattered across the first 3.5G or so of the
filesystem. So to destroy *all* of them requires some effort....
pgpg5gNaYAGr7.pgp
Description: PGP signature
