xfs
[Top] [All Lists]

Re: Segmentation fault in xfs_db frag, xfsprogs-3.1.8

Subject: Re: Segmentation fault in xfs_db frag, xfsprogs-3.1.8
From: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>
Date: Wed, 06 Jun 2012 12:06:36 +0200
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20120605234528.GD22848@dastard>
References: <4FCC77E1.4030600@xxxxxxxxxxxxxxxxx> <20120605234528.GD22848@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120427 Thunderbird/12.0.1
On 06/06/2012 01:45 AM, Dave Chinner wrote:
> No surprise if you have a large filesystem and the filesystem is
> changing while xfs_db is running. xfs_db is not coherent with
> mounted filesytems, and it is not recommended that you use it that
> way.s xfs-db is a debugging tool, not a filesystem state reporting
> tool.

Ok, thanks, didn't know that.
I would like to monitor the fragmentation value for all my mounted XFS.
I think I read in previous list messages that also other people are
using xfs_db this way. Or is there another way to get the fragmentation
value?


I found this segmentation fault error very strange, since I have been
using "echo frag | xfs_db -r" for months already on other big
filesystems - 2 x 17 TB, 1 x 25 TB, 1 x 20 TB - and NEVER got a
segmentation fault. All 4 filessystems are mounted read-write and are in
heavy IO use, nevertheless "echo frag | xfs_db -r" runs as expected (by
me), no one xfs_db run crashed with a segmentation fault at all for
months, running every weekend.
It also ran several times without giving any errors on this 80 TB XFS,
but then started to throw segmentation faults some weeks ago.


>> # mount | grep sdc
>> /dev/sdc on /backup/ES-6664 type xfs
>> (rw,noatime,attr2,nobarrier,inode64,logbufs=8,logbsize=256k,sunit=128,swidth=3712,noquota,_netdev)
>> /dev/sdc on /backup/ES-6664 type xfs
>> (ro,relatime,attr2,nobarrier,inode64,logbufs=8,logbsize=256k,sunit=128,swidth=3712,noquota,_netdev)
>>
>> The FS gets first mounted rw and then bind mounted ro on top of it.
> 
> That doesn't mean the filesystem is mount read only. The only way to
> ensure that is to remount it read only, because the bind mount
> doesn't force file descriptors that are already open to magically
> diasappear or become read-only.

Yes, thanks! I was just trying to show how the XFS was actually mounted,
and not stating that it was mounted read-only at all. Perhaps I should
have explained it better.


>> # echo frag | /opt/xfsprogs-3.1.8/sbin/xfs_db -r /dev/sdc
>> Segmentation fault
> 
> and if you clear caches before running xfs_db again?

I will try this. I unmounted the filesystem now and I am running frag,
but I will later try to reproduce the segmentation fault and then see if
clearing caches helps.

> 
>> Any clues?
> 
> Not really, but then again you are doing something that really isn't
> guaranteed to work properly in all cases. Build xfs_db from the
> latest tree and run it without stripping the binary (i.e. run it
> from the build tree), capture the core file and get a backtrace of
> where it failed from xfs_db. more than likely it will point to
> xfs_db having encountered something that is not entirely metadata
> anymore...


Many thanks Dave for all clarifications!



-- 
Richard Ems       mail: Richard.Ems@xxxxxxxxxxxxxxxxx

Cape Horn Engineering S.L.
C/ Dr. J.J. Dómine 1, 5º piso
46011 Valencia
Tel : +34 96 3242923 / Fax 924
http://www.cape-horn-eng.com

<Prev in Thread] Current Thread [Next in Thread>