Increase st_blksize to 64k

Corinna Vinschen
Wed Jan 3 12:16:00 GMT 2007

On Jan  2 13:49, Brian Ford wrote:
> On Tue, 2 Jan 2007, Christopher Faylor wrote:
> > I don't see how replacing the constant "S_BLKSIZE" with what seems to be
> > an unrelated getpagesize () makes a lot of sense.
> The st_blksize field represents the preferred I/O size (in bytes) for the
> corresponding file system.  Generally, this is the same as, or a multiple
> of the system page size for efficient cache management.  As such, I see
> nothing unusual about using that function.
> The following document confirms my suspicion that at least NTFS buffered
> I/O is done in 64k chunks:
> I believe this is a close enough parallel to the allocation granularity to
> justify using it directly.
> > Assuming that this is a good idea, should S_BLKSIZE be changed directly?
> No, S_BLKSIZE represents the actual size of a physical block on disk,
> and/or the size of the block units reported in the stat structure.
> S_BLKSIZE has historically been 512 bytes.
> These are actually two different things.

Apparently S_BLKSIZE doesn't have much meaning anymore today.  It's not
even mentioned once in SUSv3.  On Linux, S_BLKSIZE is 512 while the
standard value in st_blksize on ext2/ext3 is 4096 (typically the value is
taken from the inode of the file, resp. from information stored in the
superblock of the FS).

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 ;)


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