Date: Wed, 30 Oct 2002 13:55:39 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Marcel Moolenaar <marcel@xcllnt.net>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c disk.c libdisk.h rules.c Message-ID: <20021030133021.D3588-100000@gamplex.bde.org> In-Reply-To: <98377.1035926855@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Oct 2002, Poul-Henning Kamp wrote: > >GPT based systems like ia64 probably need some fundamental changes. > >Tools like fsck(8) require a disklabel to figure out the partition > >type. > > No actually fsck tries to guess the filesystem type and only uses > the disklabel if /etc/fstab fails to answer the question. > > Sparc64 has no disklabel either and fsck should just be muffled to > not whine if the disklabel check fails: BSD disklabels are optional > now. Labels are also used by fsck_ffs. First, they are used to get the sector size so that it can be used to misconvert block numbers in the search for the superblock. Not finding a label is not fatal in this case. SBLOCKSEARCH gives block numbers in units of DEV_BSIZE but is scaled using dev_bsize whose preferred initial value is the sector size read from the label. The correct scale factor is used if a label is not found. So the search works iff there is no label or the sector size is DEV_BSIZE (512). This bug was fixed in the kernel in rev.1.192 of ffs_vfsops.c. Second, they are used to determine the location of alternate superblocks if reading the main superblock fails and fsck_ffs is not invoked with -p or -b. Not finding a label is fatal in this case. This case was broken from 1995 to 1998 by axing newfs's support for it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021030133021.D3588-100000>