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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
