xfs
[Top] [All Lists]

Re: mkfs.xfs with a 9TB realtime volume hangs

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: mkfs.xfs with a 9TB realtime volume hangs
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sun, 11 Jan 2009 21:35:28 +1100
Cc: Jan Wagner <jwagner@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <49690F73.1070908@xxxxxxxxxxx>
Mail-followup-to: Eric Sandeen <sandeen@xxxxxxxxxxx>, Jan Wagner <jwagner@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
References: <alpine.DEB.2.00.0811141231390.23165@xxxxxxxxxxx> <49690F73.1070908@xxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
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@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@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>