Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3C042028.9B6D028A@phekda.freeserve.co.uk>
Date:	Tue, 27 Nov 2001 23:22:16 +0000
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: RESEND: Patch to computer st_blksize in struct stat
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1011119104341 DOT 8761J-100000 AT is>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> On Sun, 18 Nov 2001, Richard Dawe wrote:
> > HD, CD-ROM drives: 0s (probably too short to measure)
> > Floppy drive:      0.11s
> > Network drive:     0.06s
> >
> > In all cases the current code in CVS takes 0s on my machine (Athlon
> > 850MHz) for the same files.
> 
> Perhaps it would be useful to run the test program on many files, not
> only one file (unless you already tried that).

I thought that the idea of running one file is that it shows the extra
overhead of the statfs() for removeable and remote drives. Ah, I see, we
can't really tell the difference since current CVS has the time 0.

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

(Hint: For reproducible results, don't listen to MP3s in the background
over the network!)

I ran each of these tests multiple times, before looking at the profile
data. So this is with maximal caching of file data. I don't have any plain
ol' DOS access, so I can't test what this is like without caching. Anyway,
it looks like the overhead of the statfs() call is around ~0.06s [with
caching].

So should I call statfs() by default for all drives? The overhead doesn't
seem all that great on Windows 98 SE, so we could remove the fixed
defaults for floppies & remote drives. 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. Unless someone knows off the top
of their head how slow statfs() on plain ol' DOS. 8)

If anyone can test this for me, here's how I modified the code for
testing. I placed #ifdef/#endif in xstat.c in the following places in
_get_cached_blksize() in xstat.c:

    ...

    #ifdef HELP_PERFORMANCE
          /* Default floppy drives to 512B block size. */
          cache_blksize[0] = cache_blksize[1] = 512;
    #endif /* HELP_PERFORMANCE */
        }

    ...

      if (!cache_blksize[d])
        {
    #ifdef HELP_PERFORMANCE
          if (_is_remote_drive(d + 1))
            {
              /* Default remote drives to 32K block size. */
              cache_blksize[d] = 32768;
            }
          else
    #endif /* HELP_PERFORMANCE */

    ...

Other than that, my code was unchanged from the last diff I sent.

> > I've added code to return 512 bytes as the block size for A:, B:.
> 
> This fact should be documented in libc.info.  Some rare configurations
> might have unusual drive types mapped to A: or B:, and they might be
> surprised by this default.

I will document any fixed sizes returned.
 
> > 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. If anyone does test
the patch, please let me know what size the fstat test displays.
 
> > 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.

[snip] 
> I think we should mention the introduction of the new data types
> blkcnt_t and blksize_t here.

I'll include that in my next patch. Here's the text:

    @tindex blksize_t
    @tindex blkcnt_t
    @tindex struct stat AT r{, and }blksize_t
    The types @code{blksize_t} and @code{blkcnt_t} were added.
    @code{blksize_t} is now used for the @code{st_blksize} member of
    @code{struct stat}.

Thanks, bye, Rich =]

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/

- Raw text -