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: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
_______________________________________________________
Details:
A user is complaining about serious performance problems after upgrading
their system. I found that this was due to the following change in the
coreutils source file system.h:
coreutils-4.5.3:
#else /* HAVE_STRUCT_STAT_ST_BLOCKS */
/* Some systems, like Sequents, return st_blksize of 0 on pipes. */
# define ST_BLKSIZE(statbuf) ((statbuf).st_blksize > 0 \
? (statbuf).st_blksize : DEV_BSIZE)
coreutils-5.2.1:
#else /* HAVE_STRUCT_STAT_ST_BLOCKS */
/* Some systems, like Sequents, return st_blksize of 0 on pipes.
Also, when running `rsh hpux11-system cat any-file', cat would
determine that the output stream had an st_blksize of 2147421096.
So here we arbitrarily limit the `optimal' block size to 4MB.
If anyone knows of a system for which the legitimate value for
st_blksize can exceed 4MB, please report it as a bug in this code. */
# define ST_BLKSIZE(statbuf) ((0 < (statbuf).st_blksize \
&& (statbuf).st_blksize <= (1 << 22)) /* 4MB
*/ \
? (statbuf).st_blksize : DEV_BSIZE)
XFS filesystems can have legitimate st_blksize values that greatly exceed
4MB.
In the case of the user I referred to above, their st_blksize was 6MB. With
coreutils-4.5.3, they saw 6MB reads/writes. With coreutils-5.2.1, the
reads/writes were all 512-bytes.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17903>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
