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
