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).
Somebody will need to find time to look into what's going on.
I think it's doing lots of work in rtinit, something like
#0 xfs_rtfind_back (mp=0x7fffa69e2f30, tp=0x3afc8b0, start=115245056,
limit=0, rtblock=0x7fffa69e28b8) at xfs_rtalloc.c:83
#1 0x000000000041433c in xfs_rtfree_range (mp=0x7fffa69e2f30,
tp=0x3afc8b0, start=115245056, len=32768, rbpp=0x7fffa69e2908,
rsb=0x7fffa69e2910)
at xfs_rtalloc.c:448
#2 0x00000000004144e4 in libxfs_rtfree_extent (tp=0x3afc8b0,
bno=115245056, len=32768) at xfs_rtalloc.c:756
#3 0x0000000000403a6b in parseproto (mp=0x7fffa69e2f30, pip=<value
optimized out>, fsxp=0x7fffa69e3240, pp=0x7fffa69e2ef0, name=<value
optimized out>)
at proto.c:752
...
-Eric
|