bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #17903] cp/mv only read/write 512 byte blocks when filesystem b


From: Paul Eggert
Subject: Re: [bug #17903] cp/mv only read/write 512 byte blocks when filesystem blksize > 4MB
Date: Tue, 03 Oct 2006 15:42:30 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Tony Ernst <address@hidden> writes:

>                       && (statbuf).st_blksize != 2147421096) \

I doubt whether the HP-UX bug always results in exactly that number.

Phillip Susi <address@hidden> writes:

> In that case I suspect that XFS really should not be
> setting that value to many megabytes.

As I understand it, XFS will let a sysadmin put pretty much whatever
number they like into st_blksize, regardless of the underyling I/O
configuration, I guess under the theory that the sysadmin is always
right.

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.

2006-10-03  Paul Eggert  <address@hidden>

        * src/system.h (ST_BLKSIZE): Ceiling at SIZE_MAX / 8 + 1, not at 4
        MiB, since XFS hosts can legitimately have large values of
        st_blksize.  Problem reported by Tony Ernst in
        <http://savannah.gnu.org/bugs/?17903>.

--- src/system.h        3 Sep 2006 02:53:37 -0000       1.160
+++ src/system.h        3 Oct 2006 22:10:15 -0000
@@ -206,11 +206,14 @@
 /* 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.  */
+   Conversely st_blksize can be 2 GiB (or maybe even larger) with XFS
+   on 64-bit hosts.  Somewhat arbitrarily, limit the `optimal' block
+   size to SIZE_MAX / 8 + 1.  (Dividing SIZE_MAX by only 4 wouldn't
+   suffice, since "cat" sometimes multiplies the result by 4.)  If
+   anyone knows of a system for which this limit is too small, 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 <= SIZE_MAX / 8 + 1) \
                              ? (statbuf).st_blksize : DEV_BSIZE)
 # if defined hpux || defined __hpux__ || defined __hpux
 /* HP-UX counts st_blocks in 1024-byte units.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]