Date: Sun, 7 Jul 2002 04:40:22 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: iedowse@maths.tcd.ie Cc: Georg.Koltermann@mscsoftware.com, obrien@FreeBSD.ORG, current@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: dump(8) is hosed Message-ID: <200207071141.g67BfJ0M022797@gw.catspoiler.org> In-Reply-To: <200207071227.aa27815@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 Jul, Ian Dowse wrote: > In message <200207070458.g674wI0M021931@gw.catspoiler.org>, Don Lewis writes: >> >>I was finally finally able to reproduce this by creating a large file >>before doing the dump. Dump(8) is *very* hosed. The UFS2 import broke >>it's ability to follow multiple levels of indirect blocks. > > 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(). The only time you'll take the performance hit is on large files, since the small ones won't have indirect blocks. 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?200207071141.g67BfJ0M022797>