Re: xfs_repair segfaults with ag_stride option

[Tom Crane <T.Crane@rhul.ac.uk>]

Eric Sandeen wrote:
> On 2/6/12 5:19 AM, Tom Crane wrote:
>   
>> Eric Sandeen wrote:
>>     
>
> ...
>
>   
>>> Newer tools are fine to use on older filesystems, there should be no
>>>   
>>>       
>> Good!
>>
>>     
>>> issue there.
>>>
>>> running fsr can cause an awful lot of IO, and a lot of file reorganization.
>>> (meaning, they will get moved to new locations on disk, etc).
>>>
>>> How bad is it, really?  How did you arrive at the 40% number?  Unless
>>>   
>>>       
>> xfs_db -c frag -r <block device>
>>     
>
> which does:
>
>                 answer = (double)(extcount_actual - extcount_ideal) * 100.0 /
>                          (double)extcount_actual;
>
> If you work it out, if every file was split into only 2 extents, you'd have
> "50%" - and really, that's not bad.  40% is even less bad.
>   

Here is a list of some of the more fragmented files, produced using,
xfs_db -r /dev/mapper/vg0-lvol0 -c "frag -v" | head -1000000 | sort 
-k4,4 -g | tail -100

> inode 1323681 actual 12496 ideal 2
> inode 1324463 actual 12633 ideal 2
> inode 1333841 actual 12709 ideal 2
> inode 1336378 actual 12816 ideal 2
> inode 1321872 actual 12845 ideal 2
> inode 1326336 actual 13023 ideal 2
> inode 1334204 actual 13079 ideal 2
> inode 1318894 actual 13151 ideal 2
> inode 1339200 actual 13179 ideal 2
> inode 1106019 actual 13264 ideal 2
> inode 1330156 actual 13357 ideal 2
> inode 1325766 actual 13482 ideal 2
> inode 1322262 actual 13537 ideal 2
> inode 1321605 actual 13572 ideal 2
> inode 1333068 actual 13897 ideal 2
> inode 1325224 actual 14060 ideal 2
> inode 48166 actual 14167 ideal 2
> inode 1319965 actual 14187 ideal 2
> inode 1334519 actual 14212 ideal 2
> inode 1327312 actual 14264 ideal 2
> inode 1322761 actual 14724 ideal 2
> inode 425483 actual 14761 ideal 2
> inode 1337466 actual 15024 ideal 2
> inode 1324853 actual 15039 ideal 2
> inode 1327964 actual 15047 ideal 2
> inode 1334036 actual 15508 ideal 2
> inode 1329861 actual 15589 ideal 2
> inode 1324306 actual 15665 ideal 2
> inode 1338957 actual 15830 ideal 2
> inode 1322943 actual 16385 ideal 2
> inode 1321074 actual 16624 ideal 2
> inode 1323162 actual 16724 ideal 2
> inode 1318543 actual 16734 ideal 2
> inode 1340193 actual 16756 ideal 2
> inode 1334354 actual 16948 ideal 2
> inode 1324121 actual 17057 ideal 2
> inode 1326106 actual 17318 ideal 2
> inode 1325527 actual 17425 ideal 2
> inode 1332902 actual 17477 ideal 2
> inode 1330358 actual 18775 ideal 2
> inode 1338161 actual 18858 ideal 2
> inode 1320625 actual 20579 ideal 2
> inode 1335016 actual 22701 ideal 2
> inode 753185 actual 33483 ideal 2
> inode 64515 actual 37764 ideal 2
> inode 76068 actual 41394 ideal 2
> inode 76069 actual 65898 ideal 2

The following for some of the larger, more fragmented files was produced 
by parsing/summarising the output of bmap -l

> (nos-extents size-of-smallest-extent size-of-largest-extent 
> size-of-average-extent)
> 20996 8 38232 370.678986473614
> 21831 8 1527168 555.59158994091
> 22700 8 407160 371.346607929515
> 26075 8 1170120 544.218753595398
> 27632 16 480976 311.79473074696
> 29312 8 184376 348.09115720524
> 29474 8 1632 8.06758499016082
> 33482 16 421008 292.340959321426
> 34953 8 457848 371.310044917461
> 37763 8 82184 377.083812197124
> 37826 8 970624 314.246497118384
> 39892 16 508936 345.970921488018
> 41393 8 214496 443.351291281134
> 47877 8 1047728 325.400004177371
> 50562 8 677576 328.302994343578
> 53743 8 672896 364.316841263048
> 54378 16 764280 360.091801831623
> 59071 8 910816 332.138748285961
> 62666 8 337808 312.538601474484
> 65897 16 775832 287.113040047347
> 84946 8 1457120 496.702563981824
> 117798 8 161576 53.8408461943327
> 119904 8 39048 168.37943688284
> 131330 8 65424 68.948267722531
> 174379 8 1187616 112.254113167297
> 254070 8 1418960 303.413201086315
> 313029 8 280064 62.6561756259005
> 365547 8 76864 53.5732368204362
> 1790382 8 1758176 359.880034540115
> 2912436 8 1004848 373.771190851919
 How bad does this look?

Cheers
Tom.


>> Some users on our compute farm with large jobs (lots of I/O) find they take longer than with some of our other scratch arrays hosted on other machines.  We also typically find many nfsd tasks in an uninterruptible wait state (sync_page), waiting for data to be copied in from the FS.
>>     
>
> So fragmentation may not be the problem... 
>
> -Eric
>
>   
>>> you see perf problems which you know you can attribute to fragmentation,
>>> I might not worry about it.
>>>
>>> You can also check the fragmentation of individual files with the
>>> xfs_bmap tool.
>>>
>>> -Eric
>>>   
>>>       
>> Thanks for your advice.
>> Cheers
>> Tom.
>>
>>     
>>>  
>>>       
>>>> Tom.
>>>>
>>>> Christoph Hellwig wrote:
>>>>    
>>>>         
>>>>> Hi Tom,
>>>>>
>>>>> On Wed, Feb 01, 2012 at 01:36:12PM +0000, Tom Crane wrote:
>>>>>  
>>>>>      
>>>>>           
>>>>>> Dear XFS Support,
>>>>>>    I am attempting to use xfs_repair to fix a damaged FS but always
>>>>>> get a segfault if and only if -o ag_stride is specified. I have
>>>>>> tried ag_stride=2,8,16 & 32.  The FS is approx 60T. I can't find
>>>>>> reports of this particular problem on the mailing list archive.
>>>>>> Further details are;
>>>>>>
>>>>>> xfs_repair version 3.1.7, recently downloaded via git repository.
>>>>>> uname -a
>>>>>> Linux store3 2.6.18-274.17.1.el5 #1 SMP Wed Jan 11 11:10:32 CET 2012
>>>>>> x86_64 x86_64 x86_64 GNU/Linux
>>>>>>             
>>>>>>             
>>>>> Thanks for the detailed bug report.
>>>>>
>>>>> Can you please try the attached patch?
>>>>>
>>>>>         
>>>>>           
>>>> _______________________________________________
>>>> xfs mailing list
>>>> xfs@oss.sgi.com
>>>> http://oss.sgi.com/mailman/listinfo/xfs
>>>>     
>>>>         
>>>   
>>>       
>
>   

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs