On Tue, Oct 03, 2006 at 03:42:30PM -0700, Paul Eggert wrote:
The GNU philosophy is to avoid arbitrary limits, so I installed the
following patch, in an attempt to do a minimal sort of sanity check
(catching the HP-UX bug, I hope) while not overly constraining
st_blksize.
Thank you.
Tony Ernst [EMAIL PROTECTED] writes:
XFS filesystems can have legitimate st_blksize values that greatly exceed
4MB.
Thanks for reporting this. What is the largest legitimate st_blksize
value that XFS file systems can have? We can simply increase the
value to that limit.
Why not simply cap the size at 4 MB? If it is greater than 4 MB just go
with 4 MB instead of 512 bytes. In fact, you might even want to cap it
at less than 4 MB, say 1 MB or 512 KB. I think you will find that any
size larger than the 32-128 kb range yields no further performance
increase
Tony Ernst wrote:
I believe the larger block sizes are especially beneficial with RAID.
I'm adding Geoffrey Wehrman to the CC list, as he understands disk I/O
much better than I do.
I believe most kernels always performs the actual IO in the same size
chunks due to the block layer and cache,
Tony Ernst [EMAIL PROTECTED] writes:
(statbuf).st_blksize != 2147421096) \
I doubt whether the HP-UX bug always results in exactly that number.
Phillip Susi [EMAIL PROTECTED] writes:
In that case I suspect that XFS really should not be
setting that value to many
