Bytes in a Physical I/O Block

tronayne · 08-22-2009, 09:25 AM

I'm converting some utilities from Solaris to Linux and have come across one of those "little differences" (gotchas!) between System V and Linux...

I can't seem to find (in spite of a lot of looking, searching and fooling around) the equivalent of STD_BLK, the number of bytes in a physical I/O block. I pretty much know it's going to be either 512 or 1024, but would like to know the token in some system header file (if there is one); it's used something like this

Code:

...
        /*
         *      keep copying until empty; nread should equal
         *      STD_BLK except on the last read
        */
        while ((nread = read (ifdesc, buf, STD_BLK)) > 0)
                (void) write (ofdesc, buf, nread);
...

Thanks.

paulsm4 · 08-22-2009, 05:02 PM

Hi -

Please bear in mind a few points:

1. There is no global "BLOCK_SIZE" compile-time constant because the block size obviously can (and probably will!) vary depending on where your file happens to be located (for example, /dev/hdb1 might have a different block size from your CD drive, which will have a different blocksize than a remote network share).

2. The whole *point* of "file streams" is to abstract AWAY implementation details like "physical block size" (and location!).

3. As far as real-world performance considerations, trying to map your program's user-space "read's()" to physical blocks will probably be futile. It's unlikely you'll get *any* performance gains - and you might wind up over-complicating your code.

ANYWAY:
The answer to your question is "(ioctl, FIGETBSZ, &blocksize)"

'Hope that helps .. PSM

jlliagre · 08-22-2009, 05:51 PM

STD_BLK is part of the SVR4 interface definition (SVID) so this constant defined in limit.h is shared between several Unix variants based on System V. As far as I know, it doesn't serve any useful purpose outside being there to comply with the standard. Your utility that relies upon it would probably equally works but faster with a larger block size.

paulsm4 · 08-22-2009, 06:43 PM

Neither of the first two Linux boxes/GCC environments I looked at happened to have any "STD_BLK" constant defined.

And, of course, it would be pretty useless even if they did...

tronayne · 08-22-2009, 10:01 PM

Oh, gosh, didn't mean to start a firestorm, all I was looking for was a more-or-less-standard token (like BUFSIZ and other handy defined token values that make life and portability a little easier). I know that STD_BLK is a SVR4-defined token particular to individual platform implementations and I was kind of hoping that there was something similar in Linux and that I just hadn't been able to find it; only looking for portability, not blazing performance (I/O with read() and its close relatives is, I think, just about as fast as his little feet will go in any event). A call to stat() returns st_blksize, the blocksize for file system I/O in the status structure, and that would most likely be dynamic enough (and cover all the bases for every type of file media) to "emulate" STD_BLK. As it turns out, the blocksize on this machine is 4096 as reported by a call to stat(), not my WAG of 512 or 1024.

Thanks for the interesting discussion; as usual, I learn more than I knew.

jlliagre · 08-24-2009, 01:49 AM

Quote:

Originally Posted by paulsm4

Neither of the first two Linux boxes/GCC environments I looked at happened to have any "STD_BLK" constant defined.

Indeed, Gnu/Linux doesn't pretend nor need to be SVR4 compliant.

Quote:

And, of course, it would be pretty useless even if they did...

Yes, as useless as it is with Solaris

chrism01 · 08-24-2009, 01:52 AM

Y; 4k is pretty std(ish), but you might see 8k (or even larger) on DB dedicated disks.
I certainly wouldn't rely on it being a specific size if I could avoid it.