Increase st_blksize to 64k
Corinna Vinschen
corinna-cygwin@cygwin.com
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:
>
> http://research.microsoft.com/BARC/Sequential_IO/seqio.doc
>
> 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
--
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