Hi, Using dumpe2fs I have been able to determine that all of my alternate ext3 superblocks are corrupted (not clean), and only the primary superblock is valid, i.e. mount works and the ordered journal is applied. When the primary superblock gets flakey, i.e. the ext_attr Filesystem feature goes missing - not sure why this occurs. At this point, the mount does not apply the journal using the primary superblock and mount completes without it. Usually, I will resort to booting up the FC3 OS hard drive on which the ext3 filesystem resides to fix at least the primary superblock via fsck. This situation is just the reverse of the normal assumptions the kernel and filesystem make in their design, i.e. that the alternate superblocks remain intact when the primary is hosed - not a good place to be, and evidence that the situation can occur. I do not think that this is a kernel bug, but possibly an omission since it never spawns a kernel process (during idle time) to check the consistency of all of the superblocks in the filesystem, i.e. self-diagnosing and repair, during idle time - surely this would improve the reliability of the filesystem. Just a random thought I had while thinking about the problem. When I have run fsck on boot up of the FC3 OS, that seems to repair the primary superblock, but the alternates are never repaired to be consistent with the primary superblock - that's all fsck ever seems to do. Why does fsck not repair the alternate superblocks when it has opportunity to do so? Shouldn't fsck at least detect the inconsistency with the kernel assuptions that alternate superblocks are valid, and only the primary superblock needs to be repaired after something catastrophic occurs? Shouldn't the inconsistency be reported - at the very least? Or, shouldn't there be an option to direct fsck to fix alternate superblock inconsistency, if so desired? One would think so. The Linux disk in question is an 80GB SATA drive, with an ext3 filesystem where the Filesystem features are: has_journal, ext_attr, filetype, sparse_super with the good primary superblock. The alternate superblocks all are absent the ext_attr feature, and also, the primary maximum mount count is -1 when the primary superblock goes flakey. Normally, I do not boot up the FC3 OS, but mount the disk from a Live CD to move data into the Live CD environment. The FC3 kernel is a 2.6.10-1 version. The Live CD kernels are either 2.6.15.6 or 2.6.20-16-generic. Also, the Live CD e2fsprogs are 1.40 WIP for the 2.6.20-16-generic kernel vs. 1.38 for the 2.6.15.6 kernel (both of the 2.6 kernels are not FCn OS). Interestingly, the problem (flakey primary superblock where the journal is not applied) does not manifest with the 2.6.15.6 kernel Live CD, but only with the 2.6.20-16-generic kernel Live CD which I usually run currently. Recently, because I do not know the origin of the problem, I have resorted to issuing three sync commands from the Live CD environment after I have moved data to the FC3 ext3 journal filesystem (mounted with -o sync) prior to issuing a umount command. At least the file system buffers will be flushed. I do not know if not doing this previously may have contributed to the initial problem of the primary superblock going flakey or not. Will the command: e2fsck -fp /dev/sdb2 repair the alternate superblocks, and if so, should it only be run from the Live CD environment? Or, do I need to get into runlevel 1 as single user to issue the command after unmounting the hard drive in order to run it? Or, will a dd command using skip and seek for the primary and alternate superblocks correct their corruption, as in the following example: For the purpose of this example, here is a truncated list of the primary and 1st alternative superblocks from the output of the dumpe2fs command: Primary superblock at 0, Group descriptors at 1-5 Backup superblock at 32768, Group descriptors at 32769-32773 Given: FS blocksize=4096; primary superblock at=0; 1st alternative superblock at=32768 and size of superblock=1024 <=== Is this correct??? To copy the 1st backup superblock (assuming it is clean) to fix primary superblock: # dd if=/dev/sdb2 of=/dev/sdbn bs=1024 skip=32768 count=1 To copy the primary superblock (assuming it is clean) to fix the 1st backup superblock: # dd if=/dev/sdb2 of=/dev/sdbn bs=1024 seek=32768 count=1 I am leary of using the dd commands to effect the repairs to the alternate superblocks - will they work or hose the filesystem completely? My guess is that they will hose the filesystem completely. Is this correct, and why? Also, if the e2fsck -fp /dev/sdb2 command will not repair the alternate superblocks, what tool will - debugfs? And how do I use it to make the repairs? In the event that no tool will repair the alternate superblocks, what process can I use to effect the repairs to the alternate superblocks so that they can finally be in accord with the original design assumptions for the kernel and ext3 filesystem (consistent with the primary superblock)? -- Tom
On Sep 20, 2007 17:36 -0400, Thomas Watt wrote:> Using dumpe2fs I have been able to determine that all of my alternate > ext3 superblocks are corrupted (not clean), and only the primary > superblock is valid, i.e. mount works and the ordered journal is applied. > When the primary superblock gets flakey, i.e. the ext_attr Filesystem > feature goes missing - not sure why this occurs. At this point, the > mount does not apply the journal using the primary superblock and mount > completes without it. Usually, I will resort to booting up the FC3 > OS hard drive on which the ext3 filesystem resides to fix at least the > primary superblock via fsck.Normally the superblock backups are touched only when e2fsck runs. This ensures that the backups are not touched by the kernel and not also "updated" with corruption in case of a software/hardware problem. The only code I know that updates the backup superblocks is the online resizing code, because if it doesn't the backup copies will no longer be useful (i.e. any data written beyond the old end-of-filesystem would be lost).> Will the command: e2fsck -fp /dev/sdb2 repair the alternate superblocks, > and if so, should it only be run from the Live CD environment? Or, > do I need to get into runlevel 1 as single user to issue the command > after unmounting the hard drive in order to run it?The e2fsck should handle it. Can you post the differences between the bad and good superblocks before you do so? Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
Hi Andreas, Thank you for replying. I have written a metascript which generates a shell script to dump all of the superblock information you have requested, however, only the primary and first backup are compared and then the first backup is compared with the remaining bad backup superblocks. That's not exactly what you requested, but will it suffice? If not, I can easily fix it to make the comparisons using the primary (good) superblock as the anchor instead of the (bad) first backup superblock. Outputs are: text, binary, and xxd hex dump formats with separate subdirectories and comparison scripts. I have noticed that a lack of textual difference in broken superblocks does not correlate in binary difference - i.e. they are different. I understand that there was a previous kernel bug in the mount command regarding the -o sync option, and that it has been fixed in a subsequent release. Consequently, I am for the moment not using that option on mounting the FC3 disk. In what version of the kernel was the fix for the mount command -o sync bug? I suppose I still have a question that if the online resizing code is the only other code to touch the backup superblocks (out of necessity), then what is the recommended frequency on running e2fsck with what parameters to insure that the backup superblocks remain in good, usable condition? Should this be done within FC3 natively in single user mode or will a Live CD environment with a newer version of e2fsck be more appropriate? Regards, -- Tom On Sep 20, 2007 17:36 -0400, Thomas Watt wrote:> Using dumpe2fs I have been able to determine that all of my alternate > ext3 superblocks are corrupted (not clean), and only the primary > superblock is valid, i.e. mount works and the ordered journal is applied. > When the primary superblock gets flakey, i.e. the ext_attr Filesystem > feature goes missing - not sure why this occurs. At this point, the > mount does not apply the journal using the primary superblock and mount > completes without it. Usually, I will resort to booting up the FC3 > OS hard drive on which the ext3 filesystem resides to fix at least the > primary superblock via fsck.Normally the superblock backups are touched only when e2fsck runs. This ensures that the backups are not touched by the kernel and not also "updated" with corruption in case of a software/hardware problem. The only code I know that updates the backup superblocks is the online resizing code, because if it doesn't the backup copies will no longer be useful (i.e. any data written beyond the old end-of-filesystem would be lost).> Will the command: e2fsck -fp /dev/sdb2 repair the alternate superblocks, > and if so, should it only be run from the Live CD environment? Or, > do I need to get into runlevel 1 as single user to issue the command > after unmounting the hard drive in order to run it?The e2fsck should handle it. Can you post the differences between the bad and good superblocks before you do so? Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
Hi Andreas, Here is the textual difference between the primary (good) superblock and backup (bad) superblock #1 and the xxd hex difference between them: primarysb-bkupsb1-txt.diff: < Filesystem features: has_journal ext_attr filetype sparse_super ---> Filesystem features: has_journal filetype sparse_super8c8 < Filesystem state: clean ---> Filesystem state: not clean14,15c14,15 < Free blocks: 13907467 < Free inodes: 9246071 ---> Free blocks: 18818929 > Free inodes: 956824524,26c24,26 < Last mount time: Thu Sep 27 23:47:27 2007 < Last write time: Fri Sep 28 00:20:22 2007 < Mount count: 17 ---> Last mount time: n/a > Last write time: Wed Mar 30 16:59:15 2005 > Mount count: 028c28 < Last checked: Tue Sep 18 06:56:43 2007 ---> Last checked: Wed Mar 30 16:58:55 200530c30 < Next check after: Sun Mar 16 06:56:43 2008 ---> Next check after: Mon Sep 26 17:58:55 2005primarysb-bkupsb1-xxd.diff: < 0000000: 0000 9200 5edc 2301 d197 0e00 0b36 d400 ....^.#......6.. < 0000010: 7715 8d00 0000 0000 0200 0000 0200 0000 w............... < 0000020: 0080 0000 0080 0000 0040 0000 4f79 fc46 ......... at ..Oy.F < 0000030: 0681 fc46 1100 1e00 53ef 0100 0100 0000 ...F....S....... < 0000040: ebae ef46 004e ed00 0000 0000 0100 0000 ...F.N.......... < 0000050: 0000 0000 0b00 0000 8000 0000 0c00 0000 ................ ---> 0000000: 0000 9200 5edc 2301 d197 0e00 7127 1f01 ....^.#.....q'.. > 0000010: f5ff 9100 0000 0000 0200 0000 0200 0000 ................ > 0000020: 0080 0000 0080 0000 0040 0000 0000 0000 ......... at ...... > 0000030: 3321 4b42 0000 1e00 53ef 0000 0100 0000 3!KB....S....... > 0000040: 1f21 4b42 004e ed00 0000 0000 0100 0000 .!KB.N.......... > 0000050: 0000 0000 0b00 0000 8000 0100 0400 0000 ................The Maximum mount count is 30, and I have no reason to believe that e2fsck has ever been run against this particular FC3 ext filesystem. I have every reason to believe, however, that fsck has been run on occasion when I either boot the FC3 system manually and the mount count is over 30 or when I experience the situation where the ext_attr goes missing and I then manually boot the system when it is not clean in the primary superblock. The system was created at the end of March, 2005 and as you can see from the differences the backup superblock(s) have never even been touched after their creation. What parameters do you suggest be used when e2fsck is run to repair the backup superblocks? -- Tom
Hi Ted, Thanks for the workaround, I appreciate it very much. Cheers, -- Tom -----Original Message----->From: Theodore Tso <tytso at mit.edu> >Sent: Sep 28, 2007 2:55 PM >To: Thomas Watt <tango at tiac.net> >Cc: Andreas Dilger <adilger at clusterfs.com>, ext3-users at redhat.com >Subject: Re: How are alternate superblocks repaired? > >On Fri, Sep 28, 2007 at 01:18:16AM -0400, Thomas Watt wrote: >> The Maximum mount count is 30, and I have no reason to believe that >> e2fsck has ever been run against this particular FC3 ext filesystem. >> I have every reason to believe, however, that fsck has been run on >> occasion when I either boot the FC3 system manually and the mount >> count is over 30 or when I experience the situation where the >> ext_attr goes missing and I then manually boot the system when it is >> not clean in the primary superblock. The system was created at the >> end of March, 2005 and as you can see from the differences the >> backup superblock(s) have never even been touched after their >> creation. >> >> What parameters do you suggest be used when e2fsck is run to repair >> the backup superblocks? > >Hi Tom, > >There are a couple of things going on here. First of all, out of >general paranoia, neither e2fsck nor the kernel touch backup >superblocks out of general paranoia. Most of the changes that you >pointed out between the primary and backup superblocks are no big >deal, and can easily be regenerated by e2fsck. The one exception to >is the feature bitmasks. Most of the time it's only tune2fs which >makes changes to the feature compatibility bitmasks. > >Unfortunately, the kernel does make some changes "behind the user's >back"; and one of them is the ext_attr feature flag. So thanks for >pointing that out, and I'll have to make an enhacement to e2fsck to >detect if the backup superblock's compatibility flags are different, >and if so, to update the backup superblocks. > >For now, you can work around this and force an update to the backup >superblocks by running the following command as root: > >e2label /dev/hdXXX "`e2label /dev/hdXXX`" > >This reads out the label from the filesystem, and thes sets the label >to its current value. This will force a copy from the primary to the >backup superblocks. > >Regards, > > - Ted >
Hi Ted, I just wanted to give you some feedback on running the e2label command to fix the problem of backup superblock inconsistency with the primary superblock. Since Linux filesystem name labels are optional and my filesystem volume name was not set, I wondered if that would make a difference. It did not. I did not opt to set a label, but just followed your suggested command. The following fields were updated: Filesystem features Free blocks Free inodes Last mount time Last write time Mount count Last checked Next check after The only field not updated was the Filesystem state field. So, all of the backup superblocks remain "not clean" and are now at least a lot closer to being consistent with the primary superblock - just not quite there yet as far as being usable in case the primary superblock gets hosed. At this point I don't suppose there is anyway for e2fsck to make the backup superblocks "clean" (i.e. only when the primary is clean) until your enhancement gets released. It was fairly easy to make this assessment using the script I wrote to dump all of the superblocks and make the comparisons of before and after superblock states. Checking the result was the easy part. I want to make a few changes, test them out and donate the script to the e2fsprogs project. It should make it just a little bit easier for system administrators to keep an eye on the backup superblocks, and you also might find it useful in testing your enhancement to e2fsck. The only caveat is that the script has not been tested on ext2/ext3 filesystems with blocksizes of 1024 or 2048s. There are provisions for 1024 and 2048 blocksized sytsems - that's the speculative part of the script that needs testing - assumptions always need testing/challenging - right? :) I hope this feedback helps in your enhancement efforts to e2fsck. Regards, -- Tom -----Original Message----->From: Theodore Tso <tytso at mit.edu> >Sent: Sep 28, 2007 2:55 PM >To: Thomas Watt <tango at tiac.net> >Cc: Andreas Dilger <adilger at clusterfs.com>, ext3-users at redhat.com >Subject: Re: How are alternate superblocks repaired? > >On Fri, Sep 28, 2007 at 01:18:16AM -0400, Thomas Watt wrote: >> The Maximum mount count is 30, and I have no reason to believe that >> e2fsck has ever been run against this particular FC3 ext filesystem. >> I have every reason to believe, however, that fsck has been run on >> occasion when I either boot the FC3 system manually and the mount >> count is over 30 or when I experience the situation where the >> ext_attr goes missing and I then manually boot the system when it is >> not clean in the primary superblock. The system was created at the >> end of March, 2005 and as you can see from the differences the >> backup superblock(s) have never even been touched after their >> creation. >> >> What parameters do you suggest be used when e2fsck is run to repair >> the backup superblocks? > >Hi Tom, > >There are a couple of things going on here. First of all, out of >general paranoia, neither e2fsck nor the kernel touch backup >superblocks out of general paranoia. Most of the changes that you >pointed out between the primary and backup superblocks are no big >deal, and can easily be regenerated by e2fsck. The one exception to >is the feature bitmasks. Most of the time it's only tune2fs which >makes changes to the feature compatibility bitmasks. > >Unfortunately, the kernel does make some changes "behind the user's >back"; and one of them is the ext_attr feature flag. So thanks for >pointing that out, and I'll have to make an enhacement to e2fsck to >detect if the backup superblock's compatibility flags are different, >and if so, to update the backup superblocks. > >For now, you can work around this and force an update to the backup >superblocks by running the following command as root: > >e2label /dev/hdXXX "`e2label /dev/hdXXX`" > >This reads out the label from the filesystem, and thes sets the label >to its current value. This will force a copy from the primary to the >backup superblocks. > >Regards, > > - Ted >
Hi Ted, Ok, I think I understand now. I was assuming the backup superblocks played a role without the intervention of using e2fsck and were ready to be used in a standby mode when the primary superblock gets corrupted. But, of course, there is a very real reason to be cautious when the kernel may do things unknown to users. My point-of-view was more flavored by something like the Multics structure marking that kept backup data structures free from damage. It is clear there is another strategy at work here, but one that is workable and sufficient for the ext2/ext3 filesystem. In case you are interested, here is link to a web page on Structure Marking: http://www.multicians.org/thvv/marking.html I'm so happy you sent the tip on using the e2label to correct my problem. I've attached my script which I wrote more out of curiosity than anything else: ca18e1eb99c1279e0298db56f43b1ab1 genallsbs.sh Regards, -- Tom From: Theodore Tso <tytso at mit.edu> [Add to Address Book] To: Thomas Watt <tango at tiac.net> Cc: Andreas Dilger <adilger at clusterfs.com>, ext3-users at redhat.com Subject: Re: How are alternate superblocks repaired? Date: Sep 29, 2007 9:01 AM On Sat, Sep 29, 2007 at 03:29:13AM -0400, Thomas Watt wrote:> The only field not updated was the Filesystem state field. So, all > of the backup superblocks remain "not clean" and are now at leasta> lot closer to being consistent with the primary superblock - just > not quite there yet as far as being usable in case the primary > superblock gets hosed.That's by design. The backup superblock always have the filesystem state set to "not clean". They are written out that way! Keep in mind that kernel does *not* update the backup superblocks under normal operations. So by definition, fields such as the free blocks, free inodes, last mount time, mount count, are always going to be out of date in the backup superblocks. AND THAT'S OK. The whole point of the backup superblocks is to have an extra copy of the fundamental filesystem parameters --- the blocksize, the number of inodes per block group, the block group size, the location of the inode table and the allocation bitmaps, and so on. That doesn't change under normal circumstances except when the filesystem is resized, so that's why it's OK for the kernel to not bother to update them. If the primary superblock is destroyed, e2fsck will use the backup superblocks to reconstruct the filesystem, and in the process of reconstructing the filesystem, it will update the free blocks, free inodes, and the other more transient portions of the filesystem. I'm not sure why you are so concerned about keeping every last field in the backup superblocks identical to that of the primary. There are lots of good reasons why they are not the same; the less they are modified, more likely they won't get corrupted or otherwise messed up. (For example, in addition to making the umount operation take a lot longer, the fact that the kernel never writes the backup superblocks means that we don't have to worry about what happens if the in-memory copy of the superblocks are corrupted --- say because the system administrator was too cheap to use ECC memory --- even if they are written to the primaries, the backups will still be OK for e2fsck to use for recovery purposes.) - Ted From: Thomas Watt <tango at tiac.net> [Add to Address Book] To: Theodore Tso <tytso at mit.edu> Cc: Andreas Dilger <adilger at clusterfs.com>, ext3-users at redhat.com Subject: Re: How are alternate superblocks repaired? Date: Sep 29, 2007 3:29 AM Hi Ted, I just wanted to give you some feedback on running the e2label command to fix the problem of backup superblock inconsistency with the primary superblock. Since Linux filesystem name labels are optional and my filesystem volume name was not set, I wondered if that would make a difference. It did not. I did not opt to set a label, but just followed your suggested command. The following fields were updated: Filesystem features Free blocks Free inodes Last mount time Last write time Mount count Last checked Next check after The only field not updated was the Filesystem state field. So, all of the backup superblocks remain "not clean" and are now at least a lot closer to being consistent with the primary superblock - just not quite there yet as far as being usable in case the primary superblock gets hosed. At this point I don't suppose there is anyway for e2fsck to make the backup superblocks "clean" (i.e. only when the primary is clean) until your enhancement gets released. It was fairly easy to make this assessment using the script I wrote to dump all of the superblocks and make the comparisons of before and after superblock states. Checking the result was the easy part. I want to make a few changes, test them out and donate the script to the e2fsprogs project. It should make it just a little bit easier for system administrators to keep an eye on the backup superblocks, and you also might find it useful in testing your enhancement to e2fsck. The only caveat is that the script has not been tested on ext2/ext3 filesystems with blocksizes of 1024 or 2048s. There are provisions for 1024 and 2048 blocksized sytsems - that's the speculative part of the script that needs testing - assumptions always need testing/challenging - right? :) I hope this feedback helps in your enhancement efforts to e2fsck. Regards, -- Tom m: Theodore Tso <tytso at mit.edu> [Add to Address Book] To: Thomas Watt <tango at tiac.net> Cc: Andreas Dilger <adilger at clusterfs.com>, ext3-users at redhat.com Subject: Re: How are alternate superblocks repaired? Date: Sep 28, 2007 2:55 PM On Fri, Sep 28, 2007 at 01:18:16AM -0400, Thomas Watt wrote:> The Maximum mount count is 30, and I have no reason to believe that > e2fsck has ever been run against this particular FC3 ext filesystem. > I have every reason to believe, however, that fsck has been run on > occasion when I either boot the FC3 system manually and the mount > count is over 30 or when I experience the situation where the > ext_attr goes missing and I then manually boot the system when it is > not clean in the primary superblock. The system was created at the > end of March, 2005 and as you can see from the differences the > backup superblock(s) have never even been touched after their > creation. > > What parameters do you suggest be used when e2fsck is run to repair > the backup superblocks?Hi Tom, There are a couple of things going on here. First of all, out of general paranoia, neither e2fsck nor the kernel touch backup superblocks out of general paranoia. Most of the changes that you pointed out between the primary and backup superblocks are no big deal, and can easily be regenerated by e2fsck. The one exception to is the feature bitmasks. Most of the time it's only tune2fs which makes changes to the feature compatibility bitmasks. Unfortunately, the kernel does make some changes "behind the user's back"; and one of them is the ext_attr feature flag. So thanks for pointing that out, and I'll have to make an enhacement to e2fsck to detect if the backup superblock's compatibility flags are different, and if so, to update the backup superblocks. For now, you can work around this and force an update to the backup superblocks by running the following command as root: e2label /dev/hdXXX "`e2label /dev/hdXXX`" This reads out the label from the filesystem, and thes sets the label to its current value. This will force a copy from the primary to the backup superblocks. Regards, - Ted -------------- next part -------------- A non-text attachment was scrubbed... Name: genallsbs.sh Type: application/x-shellscript Size: 14176 bytes Desc: not available URL: <http://listman.redhat.com/archives/ext3-users/attachments/20071002/7372263b/attachment.bin>
Hi Ted, That was pretty funny being "protected from preemption"! It turns out I did discover a bug in my script that I previously sent, and have fixed it. Only filesystem blocksize of 2048 needs testing/verification. Sorry for the resend - it appears my mailer decided I needed to loosen the priviledges to send the script. Here is the reworked script attached: 003a2b57b7d0c798b6d1044506634c3c genallsbs.sh Cheers, -- Tom -----Original Message----->From: Theodore Tso <tytso at mit.edu> >Sent: Oct 2, 2007 5:59 PM >To: Thomas Watt <tango at tiac.net> >Cc: Andreas Dilger <adilger at clusterfs.com>, ext3-users at redhat.com >Subject: Re: How are alternate superblocks repaired? > >On Tue, Oct 02, 2007 at 03:38:47PM -0400, Thomas Watt wrote: >> In case you are interested, here is link to a web page on Structure Marking: >> http://www.multicians.org/thvv/marking.html > >I actually have used a Multics system way back when (I was actually >logged into MIT Multics when it was finally shutdown[1]). The com_err >library and the ss library in e2fsprogs was largely inspired from >Multics, and I do use structure magic numbers in memory to protect >against programming errors, which is basically a very simple structure >marking technique. > >I'm a bit dubious about how useful simply structure matching would be >for modern Linux systems, since a large number of errors really are >silent bit flips in the data, that wouldn't be detected simply by >checking the expected structure ID at the beginning of the on-disk >object. We are planning on adding checksum to metadata for ext4, >which will help a lot in terms of detected bad metadata. > >Regards, ("You are protected from preemption" :-) > >[1] http://stuff.mit.edu/afs/sipb/project/eichin/sipbscan/ > > - Ted-------------- next part -------------- A non-text attachment was scrubbed... Name: genallsbs.sh Type: application/x-shellscript Size: 13942 bytes Desc: not available URL: <http://listman.redhat.com/archives/ext3-users/attachments/20071003/1b7a2726/attachment.bin>
Thanks. Turns out there was a way to fully test the script which is attached: eb89e01bde14d4ca25c778bbb13fb5fa genallsbs.sh.bz2 Looking forward to the new and improved filesystems from you and your filesystem colleagues. Regards, -- Tom -----Original Message----->From: Theodore Tso <tytso at mit.edu> >Sent: Oct 3, 2007 2:44 PM >To: Thomas Watt <tango at tiac.net> >Cc: Andreas Dilger <adilger at clusterfs.com>, ext3-users at redhat.com >Subject: Re: How are alternate superblocks repaired? > >On Tue, Oct 02, 2007 at 05:59:11PM -0400, Theodore Tso wrote: >> I'm a bit dubious about how useful simply structure matching would be >> for modern Linux systems, since a large number of errors really are > sorry, I meant to say "filesystems", not "systems" above >> silent bit flips in the data, that wouldn't be detected simply by >> checking the expected structure ID at the beginning of the on-disk >> object. We are planning on adding checksum to metadata for ext4, >> which will help a lot in terms of detected bad metadata. > > - Ted-------------- next part -------------- A non-text attachment was scrubbed... Name: genallsbs.sh.bz2 Type: application/x-bzip Size: 3713 bytes Desc: not available URL: <http://listman.redhat.com/archives/ext3-users/attachments/20071004/4f962131/attachment.bin>