On Thu, Jun 24, 2010 at 06:35:42PM +0300, Yannis Klonatos wrote: > στις 6/24/2010 6:21 PM, O/H Eric Sandeen έγραψε: > >On 06/24/2010 09:11 AM, Yannis Klonatos wrote: > >>2) The output of xfs_bmap in the lineitem.MYI table of the TPC-H > >>workload is at one run: > >> > >>/mnt/test/mysql/tpch/lineitem.MYI: > >> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > >> 0: [0..6344271]: 11352529416..11358873687 31 (72..6344343) 6344272 > >> 1: [6344272..10901343]: 1464842608..1469399679 4 (112..4557183) 4557072 > >> 2: [10901344..18439199]: 1831053200..1838591055 5 (80..7537935) 7537856 > >> 3: [18439200..25311519]: 2197263840..2204136159 6 (96..6872415) 6872320 > >> 4: [25311520..26660095]: 2563474464..2564823039 7 (96..1348671) 1348576 > >> > >>Given that all disk blocks are in units of 512-byte blocks, if I > >>interpret the output > >>correctly the first file is at block 1465352792 = 698.4GByte offset and > >>the last block > >>is at 5421.1GByte offset, meaning that this specific table is split over > >>a 4,7TByte distance. > >The file started out in the last AG, and then had to wrap around, > >because it hit the end of the filesystem. :) It was then somewhat > >sequential in AGs 4,5,6,7 after that, though not perfectly so. > > > >This run was with a clean filesystem? Was the mountpoint > >/mnt/test? XFS distributes new directories into new AGs (allocation > >groups, or disk regions) for parallelism, and then files in those dirs > >start populating the same AG. So if /mnt/test/mysql/tpch ended up in > >the last AG (#31) then the file likely started there, too. > > Ok. Your argument makes a lot of sense. However, this is a clean > file system (mount point /mnt/test), and > I am certain that the files copied before the aforementioned index > file (lineitem.MYI) require 28GByte space > in total. So, this still raises the question why XFS splitted these > files in a way that caused the whole file system > space to be "covered", and the lineitem file to be placed starting > at the end of the FS (as you mentioned). XFS spreads allocation out over it's entire address space to enable utilisation of all the disks backing the filesystem (think linear concatenation of devices). This is sub-optimal for a small number of spindles, but XFS is designed to scale to hundreds to thousands of disks effectively. > >>4) The version of xfsprogs is 2.9.4 (acquired with xfs_info -v) and the > >>version of the kernel is 2.6.18-164.11.1.el5. > >Ah! A Red Hat kernel; have you asked your Red Hat support folks for > >help on this issue? > > I suppose that they will redirect me back to you, won't they? :-) Or me ;) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
