* 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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox