OT: multi-platform *nix blocksize detection

[Fairlight]

The honourable and venerable Ron Kracht spoke thus:
> Take a look at the comments in the bits/stat.h file on a Linux system. 
> You'll see that st_blocks is the number of 512 byte blocks in the file - 
> regardless of the the actual block size.

Excellent point, Ron.  You are indeed correct, verified on Cobalt's 2.2
kernel and SuSE 9.0's 2.4 kernel.  THANK you for explaining that to me.

> I haven't played with this for many years but I believe you will get an 
> accurate read of what you want by looking at st_blksize. While 

Nope.  :-/  That's what I -originally- meant to do.  You know how I said
that Cobalt is 1K blocks and SuSE is 2K blocks?  In -both- cases, looking
at st_blksize is 4096.  Useless.  Given the comments I saw about the
"optimal block size for I/O", I take this to mean that it's not the actual
fs block size (I wish, as it would clear up many things), but rather the
threshhold below which the OS prefers not to be bothered with interaction
with the filesystem, as a performance enhancement presumably.

> st_blksize is commented as the "optimal block size for I/O" it seems to 
> me, and it also seems reasonable, that this matches the actual block 
> size used by the filesystem. A little testing should tell you if my 
> recollection is accurate or not.

Nope.  Tested that yesterday.  Both linux systems running differing kernel
trees both return 4096 for st_blksize, even though one is 1K blocks and the
other is 2K blocks in the filesystem itself.  I -would- expect it to work
as you say, and perhaps it does on other unixen--Solaris kicks back 8192,
and they're indeed using 8K blocks.

I think on linux it's simply the VFS layer preferred I/O transactional
blocksize--the equivalent of setting wsize and rsize for NFS or SMB.  But
as with those, under linux it appears to share nothing in common with the
actual fs -storage- block size of the filesystem itself.

Rather knackered, that.  :-/  I've seen many accusations of linux not doing
things as expected over the years.  Many of these can be glossed over
depending on which behaviuor you've observed in various other makes and
models of *nix.  This is the first time I've had a disagreement with how
they implemented something basic.

Good thought.  Wish you'd (and I'd, yesterday) been right about that.  That
was my -original- intent until I saw the math just -didn't- work out.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html