lkml.org 
[lkml]   [1999]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Ext2 defragmentation
"Theodore Y. Ts'o" wrote:
>
>
>
> Doesn't this change in e2fsprogs make it harder to recover data from
> a corrupt fs since there's no obvious way to know where to look for
> backup superblocks.
>
> Yes, there is that downside. We should have put at least one set of
> backup superblocks at a fixed location, but that's one of the things we
> didn't do when we were originally designing ext2. Hmmm... it may be
> possible to put a fixed superblock on larger-sized filesystems by having
> mke2fs create a .backup_superblock file, which make life easier for some
> folks. (Folks who decide they desparately need the extra space back can
> just delete the file.)
>
> - Ted

Isn't this still the problem of storing fs metadata within a potentially
corrupt fs? I think storing the backup superblock locations outside the fs
would be a good idea. Is it possible to add an option to tune2fs to report
this info so one could store it on a floppy or print it or something?

I've noticed another anomaly. When mke2fs 1.18 creates a 1.3GB partition, it
says the first backup superblock is at 32768 not 32769. Is this an off-by-one
error?

--
IE5 is the best looking program to ever screw up my system

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:1.901 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site