newfs: useless/bogus check if new last block can be accessed?

Juli Mallett jmallett at
Fri May 9 18:32:29 PDT 2003

* Lukas Ertl <l.ertl at> [ Date: 2003-05-09 ]
	[ w.r.t. Re: newfs: useless/bogus check if new last block can be accessed? ]
> On Sat, 10 May 2003, Poul-Henning Kamp wrote:
> > In message <20030510002107.T638 at>, Lukas Ertl writes:
> >
> > >I don't think it does any harm to keep it (WRT to getting a working
> > >filesystem), but since I don't see how it would signal an error (and this
> > >is why I posted the question) I'd vote for removing the check.
> > >
> > >And while we're here: shouldn't wtfs() actually give a return value and
> > >not be just static void? (In terms of: "be a good programmer and check the
> > >return values of your syscalls...") I think it's called often enough in
> > >newfs to qualify for a check :-)
> >
> > Get in touch with jmallett at who has been actively trying to
> > improve the UFS/FFS tools for some time, it sounds like the two of you
> > are on the same page :-)
> :-)
> Ok, although I guess she's on this list anyway, I'm CC'ing her and hope
> she's interested if I can come up with some fixes...

I at one point had some warnx calls (at minimum, since things tend to work
and it's better to let someone shoot their foot maybe than use errx, cause
at that point, it's a bit late.) and so on.  I didn't ever get them into
CVS as I was working on general libufs-ification at the time of newfs, and
then tracking down why that broke things (*blush*), and I didn't want to
put in too many new failure cases I could be blamed for :)  Do a bunch of
testing with errx, maybe, see if things blow up, and if so, maybe make it
advisory (e.g. warnx) and track down the real root of the problem.  When I
was discussing some generalised API for accessing members of the sblock
(which went nowhere due to over-engineering, and too much, yeah,
it went nowhere), one of the things I wanted to do was have a "naive" flag
as part of an (undeveloped) generalised flags (external, not like MINE_)
interface, which would let libufs do the exploding, if things went wrong.

But that's beyond what you're talking about.  Do some testing, maybe some
cleanups along what you mentioned, I'll be glad to see it done, as long as
things still work :)

juli mallett. email: jmallett at; efnet: juli;

More information about the freebsd-fs mailing list