Increase st_blksize to 64k

Corinna Vinschen
Wed Jan 3 15:59:00 GMT 2007

On Jan  3 10:40, Christopher Faylor wrote:
> On Wed, Jan 03, 2007 at 02:35:57PM +0100, Corinna Vinschen wrote:
> >On Jan  3 06:20, Eric Blake wrote:
> >> Hash: SHA1
> >> 
> >> According to Corinna Vinschen on 1/3/2007 5:16 AM:
> >> > 
> >> > Setting st_blksize to 64K might be a good idea for disk I/O if the value
> >> > is actually used by applications.  Do you have a specific example or a
> >> > test result from a Cygwin application which shows the advantage of
> >> > setting st_blksize to this value?  I assume there was some actual case
> >> > which led you to make this change ;)
> >> 
> >> Did you read the original link?
> >>
> >
> >Urgh, sorry, no.  I missed it even twice, once when scanning the Cygwin
> >list to see what happened since Christmas, and once in Brian's mail
> >starting this thread.
> >
> >So it appears to make much sense to set the blocksize to 64K.  The
> >only question would be whether to use getpagesize() or a hard coded
> >value.  It seems to me that the 64K allocation granularity and using
> >64K as buffer size in disk I/O coincide so I tend to agree that it
> >makes sort of sense to use getpagesize at this point.  What do you
> >think, Chris?
> I don't think getpagesize should be linked to this value.  The fact that
> both are 64K seems to be a coincidence to me.  This wasn't mentioned in
> the document that Brian mentioned was it?
> If we specifically want to use 64K block sizes then I think we should
> specifically say that rather than relying on some other unrelated mechanism
> to return a 64K constant.

Ok, I'll apply Brians patch with 64K hardcoded plus a comment why this
looks like a good idea, performance-wise.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-patches mailing list