Mail Archives: djgpp-workers/2001/11/28/03:32:32
On Tue, 27 Nov 2001, Richard Dawe wrote:
> Running the profiled fstat test program on directories with 30-60 files in
> them ("time fstat 0 <drive>:/<path>/*.* 2>/dev/null") shows that the
> current CVS and the patched version using statfs() on all drives shows the
> following:
>
> CVS CVS+st_blksize
> ------------------------------------------------------------------
> Floppy disk with 285 files in directory: 0.00s 0.06s
> CD-ROM disc with 242 files in directory: 0.22s 0.28s
> Hard disk with 285 files in directory: 0.17s 0.22s
> Network drive with 257 files in directory: 6.28s 6.33s
> [...]
> So should I call statfs() by default for all drives?
I'd prefer not to do that for floppies and networked drives, even
though the above data suggests the slow-down is negligible in the
normal case. The reason is that floppies could have damaged FATs that
could fail stat where it previously would succeed, and networked
drives could incur delays due to network problems. Since the block
size on a floppy is almost always known in advance, and for networked
drives the size is of no practical use, it doesn't seem like a risk
worth taking.
Oh, btw, statfs is non-Posix, while stat and lstat are. So we need to
make statfs a stub. Did we do that?
Another btw is that the new Posix draft defined a standard function
called statvfs (and another one called fstatvfs). Would someone
consider writing these, as more-or-less trivial wrappers for statfs?
> However, it seems to me that we need someone with access to a
> machine with plain ol' DOS to test it, to see what the overhead is
> without caching.
If you send me a source of a test program, I can run it on DOS 5.0.
> > > I've also defaulted the block size to 32K for remote drives. If you
> > > don't think 0.06s is much overhead, then I can remove the hard-coded
> > > size for remote drives.
> >
> > I think a constant default for networked drives is okay, since it
> > isn't meaningful in many cases, anyway. However, 32K seems a bit
> > large; how about 4KB instead?
>
> I chose 32K, because that's what I found on my system.
How did you find that? What methods of reporting the block size of a
remote drive did you use?
> > > Shouldn't xstat.c include sys/stat.h, to get common
> > > definitions for _STAT_*?
> >
> > Yes, it should. Thanks for catching this.
>
> Oops, actually xstat.h includes sys/stat.h. But: _STAT_* are defined in
> sys/stat.h and xstat.c; _STFAIL_* are defined in sys/stat.h and xstat.h.
> Since the definitions are the same, there are no warnings.
I think we should remove the duplicate definitions. They are probably
a left-over from the initial coding of these functions.
- Raw text -