All of lore.kernel.org
 help / color / mirror / Atom feed
* xfs_fsr XFS_IOC_SWAPEXT failed
@ 2012-03-23 13:57 Gabriel VLASIU
  2012-03-23 19:41 ` Eric Sandeen
  0 siblings, 1 reply; 11+ messages in thread
From: Gabriel VLASIU @ 2012-03-23 13:57 UTC (permalink / raw)
  To: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Can somebody explain the reason for this error:

# xfs_fsr -vvv \{aed7ec6a-7659-494a-8837-cabce9e6f506\}.vdi                                                            
{aed7ec6a-7659-494a-8837-cabce9e6f506}.vdi
XFS_IOC_SWAPEXT failed: {aed7ec6a-7659-494a-8837-cabce9e6f506}.vdi: Invalid argument

I can copy this file and there are no errors reported by virtualbox.
The kernel version is 3.3.0.

Thank you.


Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9sgVEACgkQeWrbH+aEIG4yJwCdEQ+7j+dEO83ThG6LqRXujyZ8
VBcAn2EjjzhaUqDcvVAOXuhiic91DEJg
=ZAR0
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-23 13:57 xfs_fsr XFS_IOC_SWAPEXT failed Gabriel VLASIU
@ 2012-03-23 19:41 ` Eric Sandeen
  2012-03-23 20:01   ` Gabriel VLASIU
  0 siblings, 1 reply; 11+ messages in thread
From: Eric Sandeen @ 2012-03-23 19:41 UTC (permalink / raw)
  To: Gabriel VLASIU; +Cc: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/23/12 8:57 AM, Gabriel VLASIU wrote:
> Hi!
> 
> Can somebody explain the reason for this error:
> 
> # xfs_fsr -vvv \{aed7ec6a-7659-494a-8837-cabce9e6f506\}.vdi
> {aed7ec6a-7659-494a-8837-cabce9e6f506}.vdi
> XFS_IOC_SWAPEXT failed: {aed7ec6a-7659-494a-8837-cabce9e6f506}.vdi: Invalid argument
> 
> I can copy this file and there are no errors reported by virtualbox.
> The kernel version is 3.3.0.

Check kernel logs / dmesg?

- -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/

iQIcBAEBAgAGBQJPbNHbAAoJECCuFpLhPd7g3f4QAMYjEZyP1PnvhJcaHgYhygZI
eI2l2Bk5K7UfNY20lKwOe8A07CeLBXZ3QdjfBWM5QwUZB2gxYuM4d0G2H+XIqLsr
2Qe7+zarR6heV9qT3QmNE93bDKVgPG/rU3IYchL40THMFlkobC0sk9Kxu9S5Trrb
ssEOJFmcnVhtaCc6mle1Sac+SfArDixPbVlSny5esdQXh88v1Or7ixj+fL4/ck3c
680koIyoBnBr8po/dhDASzcW7H3wSuzldweOtbiq2JrHAIOUV9qY+A2f49ieUmt+
9TZUa86jsPNWE5DHn5BQ0C0OBphDXDfCEhNELf33sbOKUK0KkKLD3anloX/LtlKi
OrFlKstFgrdlDg0QY8yimYbxJvLAd48oA7qHqMKg8+moq9H//RP56DJJ7SfrL0G7
E7/0+Jxd9ii7d9cNHEAlxVYRY9JQT9G0hCL17NFxTBProHhhCmSZihil5QYMno9o
mO6Goh5DupCHnRSmj+M9GrhHHNiWpzLwwgAIMnadchyzSzrnCmSfU3Xsfw40JpaS
w654Full2tEWjszxSjox3smeGjR22//hh1koXMjdavbwwh9suRIjHegUl+U/bo0p
kGcNDwJiZD2O9vx2EuNfcDZbOB7UjSuE8eLzy5Nizmo8/e+x1q7YdmOJW12nkwzV
TG6nlVlk31LQhiMq1BDQ
=VaL/
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-23 19:41 ` Eric Sandeen
@ 2012-03-23 20:01   ` Gabriel VLASIU
  2012-03-23 20:05     ` Eric Sandeen
  0 siblings, 1 reply; 11+ messages in thread
From: Gabriel VLASIU @ 2012-03-23 20:01 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 23 Mar 2012, Eric Sandeen wrote:

> Check kernel logs / dmesg?
xfs_swap_extents: inode 0x400dd2e4 format is incompatible for exchanging.

Also xfs_repair does not report anything wrong.


Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9s1q4ACgkQeWrbH+aEIG7cbQCggnj+KBd/DNaqIslz7hu/uprI
VvYAniFH5PPOhbMCpEuzrsa5v4s+nzMm
=8WGr
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-23 20:01   ` Gabriel VLASIU
@ 2012-03-23 20:05     ` Eric Sandeen
  2012-03-23 20:22       ` Gabriel VLASIU
  0 siblings, 1 reply; 11+ messages in thread
From: Eric Sandeen @ 2012-03-23 20:05 UTC (permalink / raw)
  To: Gabriel VLASIU; +Cc: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/23/12 3:01 PM, Gabriel VLASIU wrote:
> On Fri, 23 Mar 2012, Eric Sandeen wrote:
> 
>> Check kernel logs / dmesg?
> xfs_swap_extents: inode 0x400dd2e4 format is incompatible for exchanging.
> 
> Also xfs_repair does not report anything wrong.

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.

Thanks,
- -Eric


> 
> 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/

iQIcBAEBAgAGBQJPbNeYAAoJECCuFpLhPd7g7oMQAJj7eeTurTYhjUxHpt09/y6G
EwGsjn8CnicpzYgmZ8KckZxeW8rdrxn6fspgYKTkVd8zuolgSw0CSmtO78Cn3wr/
SvJo5XPR61gFrDTGyhQGdLt13h/U096gNMS3lZnTWM7Cydkgw8Uv0VD6vX42iO9L
qzn7nAAypRm3Bd5KdNCDBbA3Y2sovjqixE/W5qYSDt0OzkEXwSpj/0VN/Dk1xPEz
n2eEvFDx3KoaEyBQWlaN02c+WHsDsfNjp+qIlgyCp3fa78Ho+I1WJGQ9tQzsAmLb
u98WkGkMx66BswAiFIIMq9LeljUQA69oIpCUS1ZWzW71/BZEwAKwfBeBa5n4aVJz
3cQjpGVR9uVfOvBcQB5oS+gjLcTF2A6HXI4DEe0xU90VeRotEj/Y0HgNhHhIxDef
Qq7u9w8cChdR7dIIVBNoTbGGV3OtDUo+LPFCcTfNH4UGLM5UftGp3nbPmx+O9IcB
fBGhTn+6qb4JFo4sVcIjVeQ7SFwvs36/OOFWnvtoe46kW/G/JdnMc9TQ8B0FoMn7
vRtqj9eJ8pDdxefdTVMtKxuze135FGTByxB6KrwOWw87KWP7NgU/29UBAVp1WdP5
GRUxnTLK/zvI4+sLbifwHi8H6liu87eqsKTQi/nGkjKbwLp4iOrbtV1dIxx8q++f
md88m2JD6Np7pd+mmYxI
=d4wS
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-23 20:05     ` Eric Sandeen
@ 2012-03-23 20:22       ` Gabriel VLASIU
  2012-03-23 20:46         ` Eric Sandeen
  0 siblings, 1 reply; 11+ messages in thread
From: Gabriel VLASIU @ 2012-03-23 20:22 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?
Thank you.


Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9s254ACgkQeWrbH+aEIG6axQCeMpnlT5YRoMSqYI7B+NMoE2zm
e98An3BW+/bk2jdsPcc8nE/c2c7gtimo
=D4cr
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-23 20:22       ` Gabriel VLASIU
@ 2012-03-23 20:46         ` Eric Sandeen
  2012-03-23 21:02           ` Gabriel VLASIU
  0 siblings, 1 reply; 11+ messages in thread
From: Eric Sandeen @ 2012-03-23 20:46 UTC (permalink / raw)
  To: Gabriel VLASIU; +Cc: xfs

-----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-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-23 20:46         ` Eric Sandeen
@ 2012-03-23 21:02           ` Gabriel VLASIU
  2012-03-24 18:06             ` Eric Sandeen
  0 siblings, 1 reply; 11+ messages in thread
From: Gabriel VLASIU @ 2012-03-23 21:02 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 23 Mar 2012, Eric Sandeen wrote:

> Sure, that'd be great.
OK.

> 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.
I will suppliy the metadata image as long it will remain private.

Thank you for your support. 


Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9s5PsACgkQeWrbH+aEIG4fegCghSvNfVRQMaPCXa3VNYFr3y/8
BbAAn04WPNjHA+rfDNa6mb13mvIU881Q
=nroy
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-23 21:02           ` Gabriel VLASIU
@ 2012-03-24 18:06             ` Eric Sandeen
  2012-03-24 18:52               ` Gabriel VLASIU
  2012-03-24 22:46               ` Eric Sandeen
  0 siblings, 2 replies; 11+ messages in thread
From: Eric Sandeen @ 2012-03-24 18:06 UTC (permalink / raw)
  To: Gabriel VLASIU; +Cc: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/23/12 4:02 PM, Gabriel VLASIU wrote:
> On Fri, 23 Mar 2012, Eric Sandeen wrote:
> 
>> Sure, that'd be great.
> OK.
> 
>> 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.
> I will suppliy the metadata image as long it will remain private.
> 
> Thank you for your support.

I got the image, and I can recreate the problem.

and I also get:

           <...>-27689 [000] .... 1295775.018602: xfs_swap_extent_before: dev 7:0 ino 0x400dd2e4 (target), btree format, num_extents 1463, broot size 120, fork offset 104
           <...>-27689 [000] .... 1295775.018604: xfs_swap_extent_before: dev 7:0 ino 0x83 (temp), extent format, num_extents 1, broot size 0, fork offset 104

Dave pointed out on IRC that we shouldn't ever have a file with a broot size larger than the fork offset.

i.e. the attribute fork offset is 104, which is inside the root size of 120.  So we are hitting this check and failing, which results in the EINVAL:

        /* 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)) /* 120 > 104 */
                        return EINVAL;

but the original inode seems to be in a bad state.  It's a little odd that repair never checks for this; perhaps it should.

Here is the inode in question:

# xfs_db fsr-testcase.img 
xfs_db> inode 1074647780
xfs_db> p
core.magic = 0x494e
core.mode = 0100600
core.version = 2
core.format = 3 (btree)
core.nlinkv2 = 1
core.onlink = 0
core.projid = 0
core.uid = 1000
core.gid = 1000
core.flushiter = 718
core.atime.sec = Fri Mar 23 08:38:01 2012
core.atime.nsec = 599598672
core.mtime.sec = Fri Mar 23 02:28:37 2012
core.mtime.nsec = 121002365
core.ctime.sec = Fri Mar 23 16:18:42 2012
core.ctime.nsec = 100197078
core.size = 5320806400
core.nblocks = 1299031
core.extsize = 0
core.nextents = 1463
core.naextents = 0
core.forkoff = 13
core.aformat = 1 (local)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 450641109
next_unlinked = null
u.bmbt.level = 1
u.bmbt.numrecs = 6
u.bmbt.keys[1-6] = [startoff] 1:[0] 2:[521297] 3:[586321] 4:[651345] 5:[716369] 6:[766033]
u.bmbt.ptrs[1-6] = 1:67984662 2:15986522 3:15921258 4:15856233 5:15789027 6:15719804
a.sfattr.hdr.totsize = 51
a.sfattr.hdr.count = 1
a.sfattr.list[0].namelen = 7
a.sfattr.list[0].valuelen = 37
a.sfattr.list[0].root = 0
a.sfattr.list[0].secure = 1
a.sfattr.list[0].name = "63\fijXN"
a.sfattr.list[0].value = "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
xfs_db> quit

for numrecs = 6, the root size of 120 is correct.

So it seems that perhaps our attribute fork offset has been miscalculated somehow in the past.  This'll be a tough one to figure out.

Any idea what's the oldest kernel this filesystem has been run under?  (or maybe more to the point, what kernel versions this particular file was created & modified under?)  There was an attribute fork offset calculation bug long ago, but it's long-since fixed....

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

iQIcBAEBAgAGBQJPbg0mAAoJECCuFpLhPd7gUWIQAJybMa0IBt5i+jtbqE2GWJZr
iXe+FPp7h3OJBhlHLJAXcqWduh60EedwL3fCjki6VMFCBQ3ksxmvsfx9grxpgK80
He4wXR4JUA9Kpz/xNF/N7TXq0VgbdMME+CllKpqxeBX1TRehti8jvTXz3Mwzv5nJ
scWs4GsD/PIMQE1jGZZrLufPvXdIz3adaBzLN/mrr6rjJJNTJL5IgMb43udkjZ39
ktIhei3lRBTDQSHUOjv/BaLKq90O7gfoP0SUOKYC4sXZARqpj3qHaIkf62Z8Edaz
a9WbRJ+HkmnYPpBvRAJJbYn1tVpfICNyguKVq1VGmnce7Ybg9Y700sIVwY+wCo+g
vN76MJHX93xg105BPrMzhCViHQIMqtjCapG5npLlbG8Owm+9R6dA8Regrtzc8y6y
qRPGRW8OMAFQZ4ub/XWvIRZ9zpgvlUzjPCr2NRJ4uzJB6SrEo/I+pw4U+5T0dH/O
YhvaObApHVMWBh4mqyKERTSCm+vP0ynsT4hWFbbYlyII6mnn68zxme1eTv6X6BBs
jkrrSFp2GT2y38hGG/v3N80InMHzBnuI8Ow7eqRDxJzCaOKJ4h+7HBWxS1IUGFLK
OoMU9Vx5myQDi0aA9X3LxCxAqIBHKcsLZkNupSlZwZsgIPlF9SVLwRJF1wpWC84j
8McB7+zptvPqltSCON/K
=hnid
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-24 18:06             ` Eric Sandeen
@ 2012-03-24 18:52               ` Gabriel VLASIU
  2012-03-24 22:46               ` Eric Sandeen
  1 sibling, 0 replies; 11+ messages in thread
From: Gabriel VLASIU @ 2012-03-24 18:52 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Eric.

On Sat, 24 Mar 2012, Eric Sandeen wrote:

> Any idea what's the oldest kernel this filesystem has been run under?  
> (or maybe more to the point, what kernel versions this particular file 
> was created & modified under?)  There was an attribute fork offset 
> calculation bug long ago, but it's long-since fixed....
The filesystem was created around the end of February 2010 - 25 or 26 - (I 
know that because the previous hdd had some problems and it was replaced). 
The filesystem was not modified in any way since.

At that time I had fedora 12 installed. I do not known exactly what kernel 
version I was using then but I can assume it was between 
kernel-2.6.31.12-174.2.19.fc12 (added to koji on 2010-02-11) and 
kernel-2.6.32.9-64.fc12 (added to koji on 2010-02-24).
Most likely to be 2.6.31.1[12].

See:
https://koji.fedoraproject.org/koji/packageinfo?buildStart=700&packageID=8&buildOrder=-completion_time&tagOrder=name&tagStart=0#buildlist

The filesystem was _not_ created during setup of Fedora 12. I created the 
filesystem after I upgrade the kernel to the latest available at that time 
in Fedora updates or koji (koji most likely).

Since then I had Fedora 13, 14, 15 and now I have Fedora 16.


Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9uF/8ACgkQeWrbH+aEIG7G8QCfXpPTZt4gfRUSMlV4xVnNt1aT
Y/kAn2kTrCVgOcu9s2MSbdQnTACPxi2t
=G7wy
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-24 18:06             ` Eric Sandeen
  2012-03-24 18:52               ` Gabriel VLASIU
@ 2012-03-24 22:46               ` Eric Sandeen
  2012-03-25  8:35                 ` Gabriel VLASIU
  1 sibling, 1 reply; 11+ messages in thread
From: Eric Sandeen @ 2012-03-24 22:46 UTC (permalink / raw)
  To: Gabriel VLASIU; +Cc: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/24/12 1:06 PM, Eric Sandeen wrote:
> On 3/23/12 4:02 PM, Gabriel VLASIU wrote:
>> On Fri, 23 Mar 2012, Eric Sandeen wrote:
> 
>>> Sure, that'd be great.
>> OK.
> 
>>> 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.
>> I will suppliy the metadata image as long it will remain private.
> 
>> Thank you for your support.
> 
> I got the image, and I can recreate the problem.

<snip>

> for numrecs = 6, the root size of 120 is correct.
> 
> So it seems that perhaps our attribute fork offset has been miscalculated somehow in the past.  This'll be a tough one to figure out.

Actually, scratch that idea.
 
> Any idea what's the oldest kernel this filesystem has been run under?  (or maybe more to the point, what kernel versions this particular file was created & modified under?)  There was an attribute fork offset calculation bug long ago, but it's long-since fixed....

What's interesting is that nothing actually looks corrupted (good news for you) ;)

xfs_db> 
xfs_db> inode 1074647780
xfs_db> p u.bmbt
u.bmbt.level = 1
u.bmbt.numrecs = 6
u.bmbt.keys[1-6] = [startoff] 1:[0] 2:[521297] 3:[586321] 4:[651345] 5:[716369] 6:[766033]
u.bmbt.ptrs[1-6] = 1:67984662 2:15986522 3:15921258 4:15856233 5:15789027 6:15719804
xfs_db> type text
xfs_db> p u.bmbt
00:  49 4e 81 80 02 03 00 00 00 00 03 e8 00 00 03 e8  IN..............	XFS_DINODE_MAGIC / ...
10:  00 00 00 01 00 00 00 00 00 00 00 00 00 00 02 ce  ................  ... xfs_dinode_t ...
20:  4f 6c 7c b9 23 bd 26 50 4f 6c 26 25 07 36 59 7d  Ol.....POl...6Y.
30:  4f 6c e8 b2 05 f8 e2 d6 00 00 00 01 3d 25 10 00  Ol.............. ... di_size ...
40:  00 00 00 00 00 13 d2 57 00 00 00 00 00 00 05 b7  .......W........
50:  00 00 0d 01 00 00 00 00 00 00 00 00 1a dc 3c d5  ................
60:  ff ff ff ff 00 01 00 06 00 00 00 00 00 00 00 00  ................ dinode_t | level 1, numrecs 6 / key 1
70:  00 00 00 00 00 07 f4 51 00 00 00 00 00 08 f2 51  .......Q.......Q key 2 / key 3
80:  00 00 00 00 00 09 f0 51 00 00 00 00 00 0a ee 51  .......Q.......Q key 4 / key 5
90:  00 00 00 00 00 0b b0 51 00 00 00 00 04 0d 5d 16  .......Q........ key 6 / ptr 1
a0:  00 00 00 00 00 f3 ef 5a 00 00 00 00 00 f2 f0 6a  .......Z.......j ptr 2 / ptr 3
b0:  00 00 00 00 00 f1 f2 69 00 00 00 00 00 f0 eb e3  .......i........ ptr 4 / ptr 5
c0:  00 00 00 00 00 ef dd 7c 00 00 00 00 00 33 01 00  .............3.. ptr 6 / ...
d0:  07 25 04 36 33 0c 69 6a 58 4e 00 00 00 00 00 00  ...63.ijXN......
e0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
f0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

and the (obfuscated) text around offset 0xd0 (63.ijXN) is what's in the attribute:

xfs_db> p a.sfattr
a.sfattr.hdr.totsize = 51
a.sfattr.hdr.count = 1
a.sfattr.list[0].namelen = 7
a.sfattr.list[0].valuelen = 37
a.sfattr.list[0].root = 0
a.sfattr.list[0].secure = 1
a.sfattr.list[0].name = "63\fijXN"
a.sfattr.list[0].value = "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"

But it's not overlapping the root node at all, despite the sizes calculated in xfs_dfrag.c thinking that it is.

Talking with Dave more, the way we are calculating the space for the root node (via XFS_BMAP_BROOT_SPACE_CALC) seems to be over-allocating - the value of 120 is bigger than what's actually on disk.  But that's not an on-disk value, just in memory.

So even though the offset to the attribute data within the inode is 104, and the in-memory if_broot_bytes says the root node is 120 bytes, the attr data is actually safely _past_ the root node data, which is really only about 100 bytes, not 120.

Short answer is, your file does NOT look corrupted, it's just that the checks in dfrag.c have noticed this obscure bug.

Long answer is, somebody(tm) will have to think a little more about how to fix the bug properly.

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

iQIcBAEBAgAGBQJPbk7JAAoJECCuFpLhPd7gLWMP/1Iu8CNE1dVdmCZR+9DygDld
F2cgw9lfvril/96kzC4lnHPLTOvNVWwn6894VmFIzyVWdomKy+qq0may/rp6tgYn
YDLpLCKGZHo6OblKuvrmi6UkhioeshCSIoV/MwzSUyq+dHtJ4qg90lBsJJmmd8w0
Z9DReNrejl1SoyNSH98jmJm2/FTJdLWYX7Hej/gVRl70w+hxt36L19x4EzRPnZ0B
Sy0OdBkdNC//o5tzyiTsfQqmdXYAljUoGPptXK7UUEOvaQKqS1qwSynxucQLxznt
1vXIw8FlIp1c+c/sraADOXPSrK5y8bNvWlWgL3Iqb+ELxNtEYOtJW6fypS0oeuzS
j1MEDSRYWMPhJOemDAnu7XuVxMyeBHXJRKjD8ygHmY3BxXnTkweHKd+79EJE8LcN
ItUOSPCNIC8VFXiBIUUv9Zff3WMY+2UBsWkD67m0h243ZM1+YNf2tfbLoJ/n7s1y
w3El6mE97VmQxqBZCEKenxkVxqWyALKlDJFPcAIPdgamzej8za6Rs+Sf7zmoLdwN
C/+uOJf1JyzRNEkgINPBwfUTvq9l/noULPwHowoXy2GxDZnNgmCxp0fKd0acaRCs
w6W1avsPStZMozWnF9J+lMT2HVgVg5tQZLyGN2ai06QOS83/14usaHjJFxn5tNYw
lP87ln4RSilTfzocRMPf
=4g41
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: xfs_fsr XFS_IOC_SWAPEXT failed
  2012-03-24 22:46               ` Eric Sandeen
@ 2012-03-25  8:35                 ` Gabriel VLASIU
  0 siblings, 0 replies; 11+ messages in thread
From: Gabriel VLASIU @ 2012-03-25  8:35 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: xfs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 24 Mar 2012, Eric Sandeen wrote:

> Short answer is, your file does NOT look corrupted, it's just that the 
> checks in dfrag.c have noticed this obscure bug.
Great! Thank you.
 

Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9u2OIACgkQeWrbH+aEIG7Q8ACcCNZ32VFlpdzZTvAg1LbE2sxz
ZsUAn0uoVHWDwzGstGF+Io8Uqc/s5LPk
=1ZAC
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2012-03-25  8:35 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-23 13:57 xfs_fsr XFS_IOC_SWAPEXT failed Gabriel VLASIU
2012-03-23 19:41 ` Eric Sandeen
2012-03-23 20:01   ` Gabriel VLASIU
2012-03-23 20:05     ` Eric Sandeen
2012-03-23 20:22       ` Gabriel VLASIU
2012-03-23 20:46         ` Eric Sandeen
2012-03-23 21:02           ` Gabriel VLASIU
2012-03-24 18:06             ` Eric Sandeen
2012-03-24 18:52               ` Gabriel VLASIU
2012-03-24 22:46               ` Eric Sandeen
2012-03-25  8:35                 ` Gabriel VLASIU

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.