Questions and Answers
Amy Rich
Q I'm running Solaris 10 and recently got a corrupted superblock on my boot drive. I was able to boot from the DVD and fix it by running fsck, but it made me wonder exactly what information is contained in the superblock that makes it so important? Is it where the boot block is installed?
A The superblock actually comes after the boot block and contains information about the geometry and layout of the cylinder groups and various file system parameters. The superblock is created by the mkfs (usually called by a systems administrator from newfs) program and can be later modified by the tunefs (or mkfs) program.
For a thorough understanding of the information stored in the superblock, view the source code for ufs_fs.h on cvs.opensolaris.org:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/ \
src/uts/common/sys/fs/ufs_fs.h
In particular, take a look at the following portions of the struct for fs. The first part includes variables that describe the layout and sizes of cylinders and blocks. I'm sure you'll recognize some of the information. For example, you were presumably able to recover your superblock because you used fsck with one of the alternate superblocks that is replicated across each individual cylinder group. The location of the superblock is defined by the below variable, fs_sblkno, and defaults to a location of 16 sectors (8192 bytes) into the file system partition:
uint32_t fs_link; /* linked list of file systems */
uint32_t fs_rolled; /* logging only: fs fully rolled */
daddr32_t fs_sblkno; /* addr of super-block in filesys */
daddr32_t fs_cblkno; /* offset of cyl-block in filesys */
daddr32_t fs_iblkno; /* offset of inode-blocks in filesys */
daddr32_t fs_dblkno; /* offset of first data after cg */
int32_t fs_cgoffset; /* cylinder group offset in cylinder */
int32_t fs_cgmask; /* used to calc mod fs_ntrak */
time32_t fs_time; /* last time written */
int32_t fs_size; /* number of blocks in fs */
int32_t fs_dsize; /* number of data blocks in fs */
int32_t fs_ncg; /* number of cylinder groups */
int32_t fs_bsize; /* size of basic blocks in fs */
int32_t fs_fsize; /* size of frag blocks in fs */
int32_t fs_frag; /* number of frags in a block in fs */
int32_t fs_magic; /* magic number */
Some information in the structure is pulled directly from the hardware, such as the number of tracks and sectors per cylinder:
#ifdef _LITTLE_ENDIAN
int32_t fs_state; /* file system state time stamp */
#else
int32_ fs_npsect; /* # sectors/track including spares */
#endif
int32_ fs_si; /* summary info state - lufs only */
int32_ fs_trackskew; /* sector 0 skew, per track */
int32_ fs_ntrak; /* tracks per cylinder */
int32_ fs_nsect; /* sectors per track */
int32_ fs_spc; /* sectors per cylinder */
You'll also recognize the configuration parameters below from the tunefs man page:
int32_t fs_minfree; /* minimum percentage of free blocks */
int32_t fs_rotdelay; /* num of ms for optimal next block */
int32_t fs_rps; /* disk revolutions per second */
int32_ fs_maxcontig; /* max number of contiguous blks */
int32_ fs_maxbpg; /* max number of blks per cyl group */
int32_ fs_optim; /* optimization preference, see below */
And you'll recognize some of the fields cleared at mount time from the information displayed during your fsck:
char fs_fmod; /* super block modified flag */
char fs_clean; /* file system state flag */
char fs_ronly; /* mounted read-only flag */
char fs_flags; /* largefiles flag, etc.
|
