Date: Mon, 8 Apr 2002 17:24:37 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: cvs-committers@FreeBSD.org, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sbin/newfs mkfs.c newfs.c newfs.h Message-ID: <20020408171638.W6064-100000@gamplex.bde.org> In-Reply-To: <54697.1018246653@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Apr 2002, Poul-Henning Kamp wrote: > In message <20020408154911.F5774-100000@gamplex.bde.org>, Bruce Evans writes: > >On Sun, 7 Apr 2002, Poul-Henning Kamp wrote: > > > >> phk 2002/04/07 07:57:57 PDT > >> > >> Modified files: > >> sbin/newfs mkfs.c newfs.c newfs.h > >> Log: > >> bbsize and sbsize cannot ever be trusted from the disklabel, in > >> particular as there may not be one. Remove #if 0'ed code which might > >> mislead people to think otherwise. > > > >I use this code unconditionally. bbsize and sbsize from the disklabel > >can be trusted in all cases that I know of (if there is a disklabel). > > > >Please back this out. > > I don't intend to. newfs will have to learn the new (not yet > committed) API just like any other program. I will back it out then :-). It is needed at least as a reminder that new API's should support these capabilities. newfs can determine its own super block well enough, but it currently optimizes for time and wastes a sector or two. Similarly for internal data in other filesystems. Filesystems can't determine how much space they should leave for boot blocks. Lots of time has been wasted squeezing boot code into the too-small amount of space that may have been large many years ago. 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?20020408171638.W6064-100000>