Date: Mon, 8 Jul 2002 06:49:39 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Don Lewis <dl-freebsd@catspoiler.org> Cc: iedowse@maths.tcd.ie, <Georg.Koltermann@mscsoftware.com>, <obrien@FreeBSD.ORG>, <current@FreeBSD.ORG>, <mckusick@mckusick.com> Subject: Re: dump(8) is hosed Message-ID: <20020708055510.C13007-100000@gamplex.bde.org> In-Reply-To: <200207071141.g67BfJ0M022797@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 7 Jul 2002, Don Lewis wrote: > On 7 Jul, Ian Dowse wrote: > > Thanks for tracking this down! One thing is that the code was using > > the static pointers to avoid having to malloc and free blocks every > > time. Keeping an array of NIADDR pointers and using `ind_level' as > > the index is an alternative (patch below) - I doubt the performance > > difference is noticable but it avoids having to remember the free() > > before each return. > > Prior to the UFS2 import, the code used an automatic array on the stack, > which was even cleaner. If you want to dynamically size the array and > don't mind a potential portability problem you could use alloca(). A non-dynamic auto array of unions or 2 arrays would be almost as simple as the old code. Dynamic sizing is especially moot in dump(8), since dump(8) rejects filesystems with fs_bsize > MAXBSIZE up front. (newfs(8) dumps core attempting to create such filesystems, and fsck_ffs(8) doesn't seem to be much better -- both use MAXBSIZE without checking that fs_bsize <= MAXBSIZE). BTW, I have tried reducing MINBSIZE to 512. An fs_bsize of 2048 seems to work provided some sanity tests are "fixed". newfs and fsck_ffs were happier with this than the kernel since their sanity checks are weaker (or more correct for an unlimited ufs). The sanity checks in dump seem to be more like the ones in the kernel. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020708055510.C13007-100000>