xfs
[Top] [All Lists]

Re: xfs_fsr XFS_IOC_SWAPEXT failed

To: Gabriel VLASIU <gabriel@xxxxxxxxxx>
Subject: Re: xfs_fsr XFS_IOC_SWAPEXT failed
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 23 Mar 2012 15:46:47 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <alpine.LRH.2.02.1203232220010.4760@xxxxxxxxxxxxxxx>
References: <alpine.LRH.2.02.1203231552490.21859@xxxxxxxxxxxxxxx> <4F6CD1DC.7010706@xxxxxxxxxxx> <alpine.LRH.2.02.1203232159210.3056@xxxxxxxxxxxxxxx> <4F6CD799.9090903@xxxxxxxxxxx> <alpine.LRH.2.02.1203232220010.4760@xxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/23/12 3:22 PM, Gabriel VLASIU wrote:
> On Fri, 23 Mar 2012, Eric Sandeen wrote:
> 
>> It wouldn't be expected to.
> 
>> Please see also
> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=671015
> 
>> and suggestions for tracing the error, so we know exactly which case this is.
> 
> # cat /sys/kernel/debug/tracing/trace
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 2/2   #P:2
> #
> #                              _-----=> irqs-off
> #                             / _----=> need-resched
> #                            | / _---=> hardirq/softirq
> #                            || / _--=> preempt-depth
> #                            ||| /     delay
> #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> #              | |       |   ||||       |         |
>          xfs_fsr-3895  [000] .... 108290.726664: xfs_swap_extent_before: dev 
> 7:0 ino 0x400dd2e4 (target), btree format, num_extents 1463, broot size 120, 
> fork offset 104
>          xfs_fsr-3895  [000] .... 108290.726666: xfs_swap_extent_before: dev 
> 7:0 ino 0x1c4917 (temp), extent format, num_extents 1, broot size 0, fork 
> offset 104
> 
> Should I add the trace to the bugzilla?

Sure, that'd be great.

That's a little different case than the other trace provided in that bug.  TBH 
my mind is not fully engaged enough to see which case in 
xfs_swap_extents_check_format() is tripping this up.  I think it's this:

        /* Reciprocal target->temp btree format checks */
        if (ip->i_d.di_format == XFS_DINODE_FMT_BTREE) {
                if (XFS_IFORK_BOFF(tip) &&
                    ip->i_df.if_broot_bytes > XFS_IFORK_BOFF(tip))
                        return EINVAL;

Which means (I think) that the new temp inode doesn't have enough room before 
the attribute fork, compared to the original inode.

If you want to supply an xfs_metadump metadata image (in public or in private), 
we would have a reproducer.  It obfuscates most metadata by default.

- -Eric



> Thank you.
> 
> 
> Sincerely,
> Gabriel
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPbOE2AAoJECCuFpLhPd7gCV0P/RuVduFuodbKJWDQ7Xks3ufO
MBWFS/d272KKsYEi45BmftKOw1wto3PvEtJOLL17mNOfJeGjJCruFSEizX6Px5nD
Nb5BCbmwpv+HVOaboNTTBIb2Pufp7HgOb2ReJPVxqdyJBxXtkhTCIWnGxG70xzYo
p5E6udZ9hGMzBFLLzBAaeC1Newa+1y52/i+qPdwudXYbwhSaCjsXf62Cpjm5j4iM
XEiR32coVGj2dS7BOuhPDmnrAMvRUqG4hMRLOZHC7JobVSaI3QU2gbGy+fIwZLHR
2DeQMFIMOuzE3rXTE+qjkTvGjv8DH0PAqJt2Q1bTgJzD2PGaZqvEAsCTSVF27wfv
PjZlmhLyuX6yFqMEST36csKpZ7h1ygzanipI17vD5Sj4z3aifAdXFOsuQNJCcCrl
+GDY6x4OQl2dLej6dKwTZG2V8IsUFSKxyC8lbIGJoGB0PRtPSV/KlxQzFOr+tyU9
/8pUYtmkKaDf6mLz6MK+8kjV+Zvyx33PV8I/NRaWXPTRlii8aWhJ34WuvTa/TT9K
y2R/DtorK5x52PNPFOHcGgHsj6x9KnvbD7fhOR3EC4OY7QzJHgVmnnR/nJC2TV1j
Y15EdFssIg1zZa1wajGVRpaBhhocK+lLtbdVUZS7yUQ7jSP077PgjJEaldMQkJtD
vOYfo2YVBN3V9/lCvyj9
=9+GV
-----END PGP SIGNATURE-----

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