Date: Wed, 30 Oct 2002 21:54:33 +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: <20021030212954.G5692-100000@gamplex.bde.org> In-Reply-To: <5861.1035956621@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Oct 2002, Poul-Henning Kamp wrote: > In message <20021030133021.D3588-100000@gamplex.bde.org>, Bruce Evans writes: > >On Tue, 29 Oct 2002, Poul-Henning Kamp wrote: > >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. > > The sectorsize should be discovered with DIOCGSECTORSIZE if there is > no BSD label. Actually there is no bug, provided the sector size is less than 16384 (and is a power of 2). There is just weird scaling, because fsck_ffs's bread() takes block numbers for blocks of size dev_bsize, unlike the kernel bread() which takes block numbers for blocks of size DEV_BSIZE. Some utilities even start with "blocks" of size 1 for their bread(). > >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. > > This is just too bad. If there is no BSD label there is no BSD label. > Other label formats may be able to hold the same information, or they > may not. This problem is easily avoided by not using the other label formats. 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?20021030212954.G5692-100000>