xfs_db 2.9.8: coredump

[Justin Piszcz]

On Mon, 29 Dec 2008, Dave Chinner wrote:

> On Fri, Dec 26, 2008 at 12:52:10PM -0500, Justin Piszcz wrote:
>> On Fri, 26 Dec 2008, Justin Piszcz wrote:
>>> On Fri, 26 Dec 2008, Eric Sandeen wrote:
>>>> Justin Piszcz wrote:
>>>>> # xfs_db -V
>>>>> xfs_db version 2.9.8
>>>>>
>>>>> p34:~# xfs_db -c frag -f /dev/sda1
>>>>> Segmentation fault (core dumped)
>>>>> p34:~# xfs_db -c frag -r /dev/sda1
>>>>> Segmentation fault (core dumped)
>>>>>
>>>>> (It was working BEFORE I ran xfs_fsr on it, it was at 16% fragmentation).
>>>>>
>>>>> Now it can no longer check it?
>
> xfs_db works on the block device under the filesystem, not the
> filesystem. Also, the block device on linux caches blocks, so
> after running xfs_fsr the filesystem layout has changed but the
> underlying block device now has a stale cache. hence xfs_db is
> probably being pointed off into la-la land by the stale block
> device cache.
>
> # echo 3 > /proc/sys/vm/drop_caches
Thanks Dave, I will have to add this to my scripts whenever an xfs_fsr is 
performed to avoid the problem in the future.

>
> Is your friend whenever you want to use xfs_db on a mounted
> filesystem.
>
>> p34:~# umount /r1
>> p34:~# sync
>
> And now the block device is coherent....
>
>> p34:~# xfs_db -c frag -r /dev/sda1
>> actual 365758, ideal 358711, fragmentation factor 1.93%
>
>> p34:~# mount -a
>> p34:~# xfs_db -c frag -r /dev/sda1
>> actual 365758, ideal 358711, fragmentation factor 1.93%
>> p34:~# mount -a ; dmesg | tail -n 2
>> p34:~# xfs_fsr /dev/sda1
>> /r1 start inode=0
>> p34:~# xfs_db -c frag -r /dev/sda1
>> actual 365751, ideal 358711, fragmentation factor 1.92%
>> p34:~#
>
> And this resulted in very little change  so the block device
> cache wasn't completely wacked....
>
> Cheers,
>
> Dave.
> -- 
> Dave Chinner
> david at fromorbit.com
>