On Tue, Oct 03, 2006 at 12:24:14AM -0700, Paul Eggert wrote:
> 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.
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
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
