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

Juli Mallett jmallett at FreeBSD.org
Sat May 10 13:53:18 PDT 2003


* Ian Dowse <iedowse at maths.tcd.ie> [ Date: 2003-05-10 ]
	[ w.r.t. Re: newfs: useless/bogus check if new last block can be accessed? ]
> In message <20030509223931.A75707 at FreeBSD.org>, Juli Mallett writes:
> >* Ian Dowse <iedowse at maths.tcd.ie> [ Date: 2003-05-09 ]
> >> Something like the patch below should do the trick for now. This
> >> puts back the old exit code and sector number information, but
> >> relies on the undocumented (?) behaviour of bwrite() leaving a
> >> sensible value in errno.
> >
> >That looks pretty sane.  And bwrite is undocumented.  All contracts
> >are explicit for now.  Once it's documented that changes.
> 
> Actually, the patch isn't quite right, as errno won't be set if
> there was a short write instead of an error. Unfortunately, there
> is no way to fix this without changing the libufs API, since bwrite()
> maps short writes to a -1 return value, so the caller can't tell
> whether errno is valid.

Well...

> I think bwrite() either needs to have the same semantics as pwrite(2),
> or else libufs should have the ability to display or return an error
> message. To avoid loss of previous functionality, the error message
> would need to at least include the errno string, so the string
> currently written to d_error is not sufficient.

It's fairly easy to use d_error and errno in a combination that is
both useful in the errno sense and in the descriptive error sense.
If errno is set, and d_error is set, do both, otherwise, use what
is there?

> What is using libufs's bwrite()? Would it be better to just make
> errors fatal for now so that a useful diagnostic can be printed?

Everything using libufs*.  That means every fs tool except for the
growfs and related tools, which I seem to recall rely on a lot of
voodoo.  clri does in my tree, but I don't know if I ever merged
it back in.  I'd like to have a standard erroring function in
libufs again some time, but it would need to do what's described
above, and so on.  Otherwise the individual utility/application
chooses how to format errors, which is the current issue.  I don't
see how we don't get a useful combination out of this, assuming
that an error is an error to a filesystem program, and so the
errors it gets don't have to be fully informative.  If you want to
set errno on short reads/writes, feel free to, and it can be
documented appropriately in time.

But really you want something like ufserr() from other libufs
consumers, except without lossage of errno (some or all may do
this, I forget).

Thanx,
juli.

* - A safe assumption though not true for dumpfs.
-- 
juli mallett. email: jmallett at freebsd.org; efnet: juli;


More information about the freebsd-fs mailing list