mkfs.xfs with a 9TB realtime volume hangs
Dave Chinner
david at fromorbit.com
Sun Jan 11 04:35:28 CST 2009
On Sat, Jan 10, 2009 at 03:13:23PM -0600, Eric Sandeen wrote:
> Jan Wagner wrote:
> > Hi,
> >
> > I have a RAID0 with 11x750GB+1x1TB components in the following
> > partitionable-md test setup
> >
> > root at abidal:~# cat /proc/partitions | grep md
> > 254 0 9035047936 md_d0
> > 254 1 124983 md_d0p1
> > 254 2 1828125 md_d0p2
> > 254 3 1953125 md_d0p3
> > 254 4 9031141669 md_d0p4
> >
> > Essentially, four partitions: 128MB, ~1.9GB, 2GB, 9TB. I'd like to use the
> > 1.9GB partition for xfs and put a realtime subvolume onto the same raid0
> > onto the 9TB partition. The partition tables are GDT instead of MBR to be
> > able to have >=2TB partitions.
>
> Sorry for the slow/no reply. It seems to be doing many calculations in
> rtinit, haven't sorted out what yet, but it's not likely hung, it's
> workin hard. :)
>
> If you give it a larger extsize it should go faster (if the larger
> extsize is acceptable for your use...)
>
> I tried a 4t realtime volume:
>
> mkfs.xfs -dfile,name=fsfile,size=1g -rfile,name=rtfile,size=4t,extsize=$SIZE
>
> for a few different extent sizes, and got
>
> extsize time
> ------- ----
> 512k 0.3s
> 256k 0.7s
> 128k 1.9s
> 64k 8.4s
> 32k 25.4s
> 16k 129.4s
>
> With the default 4k extent size this takes forever (the man page claims
> default is 64k, maybe this got broken at some point).
It got changed a few years back by Nathan, IIRC. I bet the time
being taken a result of the blow-out in bitmap size caused by reducing
the extent size. Given it is non-linear, it may have something to do
with cache sizes as well. e.g buftarg hashes not large enough.
Cheers,
Dave.
--
Dave Chinner
david at fromorbit.com
More information about the xfs
mailing list