public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Tom Crane <T.Crane@rhul.ac.uk>
To: xfs@oss.sgi.com
Cc: Crane T <T.Crane@rhul.ac.uk>
Subject: xfs_fsr (defragmenting) 'XFS_IOC_SWAPEXT failed: ino=xxxxxx: Invalid argument' error
Date: Tue, 14 Feb 2012 18:46:28 +0000	[thread overview]
Message-ID: <4F3AAC04.5090400@rhul.ac.uk> (raw)

Dear XFS Support,
   I am attempting to use xfs_fsr to defrag a 60TB FS but am getting 
some of the following errors;
'XFS_IOC_SWAPEXT failed: ino=xxxxxx: Invalid argument'.  Most files 
defrag w/o problem.  In an hour long run only 45/(45+6211) failed this 
way.  Here is a example chunk of syslog from a run with fsr -v which 
includes the FS level reports.


> Feb 14 15:49:13 store3 fsr[10917]: extents before:10 after:1 DONE 
> ino=797765
> Feb 14 15:49:13 store3 fsr[10917]: ino=797738
> Feb 14 15:49:13 store3 fsr[10917]: extents before:9 after:1 DONE 
> ino=797738
> Feb 14 15:49:13 store3 fsr[10917]: ino=797749
> Feb 14 15:49:14 store3 fsr[10917]: extents before:8 after:1 DONE 
> ino=797749
> Feb 14 15:49:14 store3 fsr[10917]: ino=797754
> Feb 14 15:49:15 store3 fsr[10917]: extents before:8 after:1 DONE 
> ino=797754
> Feb 14 15:49:15 store3 fsr[10917]: ino=797728
> Feb 14 15:49:17 store3 kernel: Filesystem dm-0: fs/xfs/xfs_dfrag.c: 
> inode 0xc2c20 format is incompatible for exchanging.
> Feb 14 15:49:17 store3 fsr[10917]: XFS_IOC_SWAPEXT failed: ino=797728: 
> Invalid argument
> Feb 14 15:49:17 store3 fsr[10917]: ino=797753
> Feb 14 15:49:18 store3 kernel: Filesystem dm-0: fs/xfs/xfs_dfrag.c: 
> inode 0xc2c39 format is incompatible for exchanging.
> Feb 14 15:49:18 store3 fsr[10917]: XFS_IOC_SWAPEXT failed: ino=797753: 
> Invalid argument
> Feb 14 15:49:18 store3 fsr[10917]: ino=797740
> Feb 14 15:49:20 store3 fsr[10917]: extents before:6 after:1 DONE 
> ino=797740
> Feb 14 15:49:20 store3 fsr[10917]: ino=797721
> Feb 14 15:49:21 store3 fsr[10917]: extents before:5 after:1 DONE 
> ino=797721
> Feb 14 15:49:21 store3 fsr[10917]: ino=797720
> Feb 14 15:49:22 store3 fsr[10917]: extents before:4 after:1 DONE 
> ino=797720
> Feb 14 15:49:22 store3 fsr[10917]: ino=797723
> Feb 14 15:49:23 store3 fsr[10917]: extents before:4 after:1 DONE 
> ino=797723

I have had a browse in the archive and can rule out an SElinux attribute 
difference (using xfs_io -c lsattr) between the problem files and the 
others.  It is not an busy file problem either.  I've rechecked with 
fuser and xfs_fsr -v on some of the individual files and always get the 
same error.  xfs_bmaping the problem files afterwards shows they remain 
un-defragmented.  Here is the output of xfs_bmap -v on the file with 
inode=797728.

 
> EXT: FILE-OFFSET       BLOCK-RANGE              AG 
> AG-OFFSET              TOTAL FLAGS
>    0: [0..61439]:       81759234304..81759295743 38 
> (154865408..154926847) 61440 00011
>    1: [61440..127407]:  81959724544..81959790511 38 
> (355355648..355421615) 65968 00111
>    2: [127408..127791]: 81959790528..81959790911 38 
> (355421632..355422015)   384 01111
>    3: [127792..127807]: 81959790512..81959790527 38 
> (355421616..355421631)    16 01111
>    4: [127808..157695]: 81959791104..81959820991 38 
> (355422208..355452095) 29888 00111
>    5: [157696..186367]: 81959013120..81959041791 38 
> (354644224..354672895) 28672 00011
>    6: [186368..225039]: 81980197120..81980235791 38 
> (375828224..375866895) 38672 00111


I am running the latest (v.3.1.7) xfsprogs.  My OS is SLC5 Linux with 
kernel details,
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. 

xfs_info reports the following for the FS,

xfs_info  /dev/mapper/vg0-lvol0
meta-data=/dev/mapper/vg0-lvol0  isize=256    agcount=59, 
agsize=268435424 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=15624994816, imaxpct=5
         =                       sunit=32     swidth=128 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=32 blks, lazy-count=0
realtime =none                   extsz=524288 blocks=0, rtextents=0


Is this a known problem with xfs in this kernel? Any other 
information/tests that I can supply?

Many thanks
Tom Crane

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

             reply	other threads:[~2012-02-14 18:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-14 18:46 Tom Crane [this message]
2012-02-14 23:24 ` xfs_fsr (defragmenting) 'XFS_IOC_SWAPEXT failed: ino=xxxxxx: Invalid argument' error Eric Sandeen
2012-02-21 13:00   ` Tom Crane
2012-02-15  0:28 ` Dave Chinner
2012-02-15  1:32   ` Dave Chinner
2012-02-15 13:15     ` Michael Monnerie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F3AAC04.5090400@rhul.ac.uk \
    --to=t.crane@rhul.ac.uk \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox