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. -- Brian Ford Lead Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew...
