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
URL:
http://savannah.gnu.org/bugs/?17903
Summary: cp/mv only read/write 512 byte blocks when
filesystem blksize 4MB
Project: GNU Core Utilities
Submitted by: tonyernst
Submitted on: Monday 10/02/2006 at 20:29
Category:
Follow-up Comment #1, bug #17903 (project coreutils):
I am attaching a patch against CVS that reverses the change (described above)
that caused this problem.
If you don't want to totally remove it, perhaps it could be special cased
somehow to only use the 4MB hack on HP-UX builds?
