Date: Tue, 18 Sep 2001 00:35:13 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Aram Khalili <aram@cs.umd.edu> Cc: freebsd-questions@freebsd.org Subject: Re: corrupted superblock/fsck problem Message-ID: <200109180035.aa44033@salmon.maths.tcd.ie> In-Reply-To: Your message of "Mon, 17 Sep 2001 16:49:45 EDT." <Pine.SOL.4.21.0109171645330.4082-100000@toblerone.cs.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.SOL.4.21.0109171645330.4082-100000@toblerone.cs.umd.edu>, Aram Khalili writes: >> If fsck finishes successfully using "fsck -b 32" (i.e. you are >> satisfied that the master superblock is intact), > >Is the superblock at block 32 the master superblock? The man page (I >think offhand) says that it would be the first alternate. The master superblock is at block 16; the one at block 32 is indeed the first alternate (here 'block' means a 512-byte sector). Every cylinder group (including the first one) contains a backup superblock, and then there is the master superblock in sectors 16..31. The "-b 32" option is just a handy way of avoiding the check on the very last backup superblock. >Why are backups kept then? They're not kept in synch with the master >superblock? When I read stuff about ext2fs on Linux, the documentation >said it marks all superblock copies dirty when it changes the master >superblock. Seems like a good idea. The backups are useful if the sectors containing the master superblock go bad. By never writing to them during normal operation, the idea was probably that those sectors are less likely to "wear out" than the master superblock. This is I'm sure less meaningful with modern disks. Originally, FFS would place the backup superblock at a different offset in each cylinder group to reduce the risk of all superblocks ending up on the same disk surface. Fsck makes good use of the backup superblocks too. Comparing the master superblock against the last backup superblock on the disk is a virtually foolproof way of verifying that the master superblock has not been corrupted. It can also detect many cases where the end of a disk has become corrupted, or cases where block number overflows map the end of a disk to its start. Very little information of importance changes in the master superblock, so there is no need to update the backup copies. Any summary information can be re-computed by fsck, and most fields are filesystem parameters that don't change. About the only things you might want updated in the backup superblocks are the various settings that can be changed with 'tunefs', and it has the -A option for that. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200109180035.aa44033>