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 Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils