I'll try making lots of _very_ much smaller file systems (1G each) and
see what happens.
If it makes any difference, the existing file systems on there are of
various sizes from 1G up to 350G, and all of them created and worked
fine.
The packages I collected in early March, and AFAICT they are the same
versions that are still shown as the most recent stable ones, although
it took me ages to find a working ftp server with them on this week when
I tried to update them. The full list of what I have installed is:
Kernel 2.4.20 (direct from kernel.org, not chopped up by RedHat)
acl-2.2.4-0.i386.rpm
attr-2.2.0-0.i386.rpm
dmapi-2.0.5-0.i386.rpm
dmapi-devel-2.0.5-0.i386.rpm
libacl-2.2.4-0.i386.rpm
libacl-devel-2.2.4-0.i386.rpm
libattr-2.2.0-0.i386.rpm
libattr-devel-2.2.0-0.i386.rpm
xfs-2.4.20-all-i386
xfsdump-2.2.6-0.i386.rpm
xfsprogs-2.3.9-0.i386.rpm
xfsprogs-devel-2.3.9-0.i386.rpm
I have got it scheduled to try the newer kernel (21) on there during
tomorrow, but afaict the tools / kernel patch are still the most recent
ones shown as stable on the ftp mirrors. I could be wrong though; I
couldn't get a connection to the sgi ftp server last week to try and get
an update.
I don't _think_ it's lvm that is the problem, but just in case it
matters, the version is 1.0.7 (can't get 2 to compile so sticking with 1
for now...)
Paul.
On Fri, 2003-08-01 at 16:39, Eric Sandeen wrote:
> On Fri, 1 Aug 2003, Bogdan Costescu wrote:
>
> > The numbers are not sequential, but they are monotonically increasing :-)
> > The difference between any 2 values is 8388608. Now if these are 512 byte
> > sectors, this is exactly 4294967296 bytes which is 2^32...
> >
> > This won't help you directly... but might give somebody some idea :-)
>
> The maximum AG size is 4G, for a very large fliesystem. mkfs.xfs writes
> allocation group headers at the start of each AG.
>
> howver, if this was split into small pieces & mkfs'd, then the AGs should
> not be that large... hm.
>
> -Eric
>
>
|