Mail Archives: djgpp-workers/2001/11/28/16:36:04
Hello.
Eli Zaretskii wrote:
>
> On Tue, 27 Nov 2001, Richard Dawe wrote:
>
> > 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.
Righty-ho, I'll put the code back in for 512B blocks for floppies and for
4KB blocks for remote drives.
> Oh, btw, statfs is non-Posix, while stat and lstat are. So we need to
> make statfs a stub. Did we do that?
Nope, but I'll fix that. 8)
> > 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.
Since we've decided to hardcode floppies and remote drives, there's no
need to do this.
> > Eli Zaretskii wrote:
> >
> > > 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?
statfs() returned 32K on my network drives. Is this not reliable on
network drives?
It may not be relevant, but I mapped a share from my Linux box, which is
running kernel 2.2.19 with Samba 2.0.10. The block size on the ext2
partition containing the share is 4K.
> > 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.
OK, I'll clean those up.
Bye, Rich =]
--
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/
- Raw text -