Re: [bug #17903] cp/mv only read/write 512 byte blocks when filesystem blksize > 4MB

[Tony Ernst]

On Tue, Oct 03, 2006 at 12:24:14AM -0700, Paul Eggert wrote:
> Tony Ernst <address@hidden> 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.

Hi Paul,

Unfortunately, there isn't really a "largest" legitimate st_blksize 
for XFS file systems, or I should say the maximum is whatever fits 
into a size_t (64 bits).  It's dependent on the stripe width.  I 
talked with an XFS developer who told me that 2GB is not out of the 
question today.

Now there is also the question of whether or not we really want cp/mv
allocating a 2GB buffer, but that's a different issue (and a site with 
that kind of disk set-up probably also has plenty of memory).

Since the 4MB check was to fix a specific problem on hpux, it seems 
like that check should occur inside the "# if defined hpux ..." section.
At the very least, since the bogus value returned by hpux is such an 
strange number, maybe we could just change:
                        && (statbuf).st_blksize <= (1 << 22)) /* 4MB */ \
to:
                        && (statbuf).st_blksize != 2147421096) \

I would be very surprised if 2147421096 was ever a valid st_blksize on 
any system/filesystem.  It's not a power of 2, or even a multiple 
of 128, 512, etc.

% factor 2147421096
2147421096: 2 2 2 3 3 17 37 47417

Thanks,
Tony