xfs/599 on LBS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



xfs/599 takes a long time on LBS, but it passes. The amount of time it
takes, however, begs the question if the test is could be trimmed to
do less work because the larger the block size the larger the number of
dirents and xattrs are used to create. The large dirents are not a
problem. The amount of time it takes to create xattrs with hashcol however
grows exponentially in time.

n=16k   takes 5   seconds
n=32k   takes 30  seconds
n=64k     takes 6-7 minutes
n=1048576 takes 30 hours

n=1048576 is what we use for block size 32k.

Do we really need so many xattrs for larger block sizes for this test?

S1="KNR4qb1wJE1ncgC83X2XQg7CKwuqEYQjwuX3MG1o6FyqwrCXagIYlgGqtbLlpUn9prWpkCo9ChrxJOINgc3MBSG0La6Qhm9imcduPeGtC3IvQOzuKPsQAN3O5lVS9zha1giONke1RfnTcidsDlIxNcupydmZrdJmwHU7HRxWWqLTenWh3Gi5YNWExX0Ft94NEtfY8Lov2qvYJbTA5knONimQq5wUaK1Eo449pDXTnCOTRRhPnSHMXzNqT"

mkfs.xfs -f -b size=32k -s size=4k /dev/loop16
mount /dev/loop16 /mnt
touch /mnt/foo
time xfs_db -r -c "hashcoll -a -n 1048576 -p /mnt/foo $S1" /dev/loop16 

But also, for the life of me, I can't get the btree printed out, I see
the nvlist but not btree, you can print *everything* out with just
-c 'print':

xfs_db -c 'path /hah' -c 'ablock 0' -c 'addr btree[0].before' -c 'print' /dev/loop16

  Luis



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux