On Thu, Feb 28, 2002 at 06:49:32PM +0700, Robert Elz wrote:
> 
> Something needs to look at exactly what you were doing there, and
> how the numbers reported were produced.  Some of them made little sense
> (but I didn't look at it closely enough to see why).

I didn't like them either....
I think that the byte before the write is being allocated
during either the seek or the write.
Unfortunately dd won't do a count=0 copy :-) so a silly program
would be needed (or a very close look at the fffs code) to tell
whether it is the seek() or write() that does it.  OTOH seek()
is likely to be a noop.

This is actually a bug - and will cause sparse files (with
aligned writes) to use twice as much disk space as strictly
necessary.

I also found the following comment:

 * NB: triple indirect blocks are untested.

at the top of ffs_indirtrunc (ufs/ffs/ffs_inode.c)

Trouble with testing fs code is that it is so easy to
destroy the filesystem.  Has anyone ever sussed out
a way of compiling a second copy of ffs - called (say)
testffs - so that you can isolate your system from the
code being tested.  (A load of #defines might work...)

(It also seems dangerous to me to use the file size to deterime
the size of the fragment at the end of the file.... )

	David

-- 
David Laight: david@l8s.co.uk