From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: Re: rsync and corrupt inodes (was xfs_dump problem)
Date: Thu, 1 Jul 2010 10:25:03 +0200 [thread overview]
Message-ID: <201007011025.04391@zmi.at> (raw)
In-Reply-To: <20100630233029.GO24712@dastard>
[-- Attachment #1.1: Type: Text/Plain, Size: 48931 bytes --]
On Donnerstag, 1. Juli 2010 Dave Chinner wrote:
> > From another Linux ("saturn"), I do an rsync via an rsync-module,
> > and have already 4 Versions where the ".vhd" file of that Windows
> > Backup is destroyed on "saturn". So the corruption happens when
> > starting rsync @saturn, copying orion->saturn, both having XFS.
>
> Are you running rsync locally on saturn (i.e. pulling data)? If so,
> can you get an strace of the rsync of that file so we can see what
> the order or operations being done on the file is. If you are
> pushing data to saturn, does the problem go away if you pull it (and
> vice versa)?
Oh dear, I made a mistake. It's a push @orion, doing
rsync -aPvHAXy / saturn::orionbackup/
The problem is: I cannot 100% replicate it. I found the problem once,
moved the dir with the broken file away and synced again. Again broken.
Then I reported here. Meanwhile, Windows has done a new backup, that
file doesn't seem to get broken. But with another fresh Windows backup,
it came again. I don't know if it depends on the file, it happened 4
times until now.
I rsynced today 3 times, twice with the openSUSE kernel and once with
2.6.34, no problem. Sorry (or maybe "lucky me"?).
> > 852c268f-cf1a-11de-b09b-806e6f6e6963.vhd* ??????????? ? ? ?
> > ? ? 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd
>
> On the source machine, can you get a list of the xattrs on the
> inode?
How would I do that? "getfattr" on that file gives no return, does that
mean it doesn't have anything to say? I never do that things, so there
shouldn't be any attributes set.
> > and on dmesg:
> > [125903.343714] Filesystem "dm-0": corrupt inode 649642 ((a)extents
> > = 5). Unmount and run xfs_repair. [125903.343735]
> > ffff88011e34ca00: 49 4e 81 c0 02 02 00 00 00 00 03 e8 00 00 00 64
> > IN.............d [125903.343756] Filesystem "dm-0": XFS internal
> > error xfs_iformat_extents(1) at line 558 of file
> > /usr/src/packages/BUILD/kernel-desktop-2.6.31.12/linux-2.6.31/fs/xf
> >s/xfs_inode.c. Caller 0xffffffffa032c0ad
>
> That seems like a different problem to what linda is seeing
> because this is on-disk corruption. can you dump the bad inode via:
>
> # xfs_db -x -r -c "inode 649642" -c p <dev>
Uh, that's a long output.
# xfs_db -x -r -c "inode 649642" -c p /dev/swraid0/backup
core.magic = 0x494e
core.mode = 0100700
core.version = 2
core.format = 2 (extents)
core.nlinkv2 = 1
core.onlink = 0
core.projid = 0
core.uid = 1000
core.gid = 100
core.flushiter = 4
core.atime.sec = Mon Jun 14 10:53:41 2010
core.atime.nsec = 000000000
core.mtime.sec = Sat Jun 12 03:15:57 2010
core.mtime.nsec = 000000000
core.ctime.sec = Mon Jun 14 10:53:41 2010
core.ctime.nsec = 180152802
core.size = 36569189376
core.nblocks = 8928025
core.extsize = 0
core.nextents = 5
core.naextents = 0
core.forkoff = 9
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 = 112968465
next_unlinked = null
u.bmx[0-4] = [startoff,startblock,blockcount,extentflag] 0:
[0,549849376,2097151,0] 1:[2097151,551946527,2097151,0] 2:
[4194302,554043678,2097151,0] 3:[6291453,556140829,2097151,0] 4:
[8388604,558237980,539421,0]
a.sfattr.hdr.totsize = 4
a.sfattr.hdr.count = 40
a.sfattr.list[0].namelen = 35
a.sfattr.list[0].valuelen = 136
a.sfattr.list[0].root = 1
a.sfattr.list[0].secure = 0
a.sfattr.list[0].name =
"\035GI_ACL_FILE\000\000\000\005\000\000\000\001\377\377\377\377\000\a\000\000\000\000\000\002\000\000\004"
a.sfattr.list[0].value =
"\346\000\a\000\000\000\000\000\004\377\377\377\377\000\006\000\000\000\000\000\020\377\377\377\377\000\000\000\000\000\000\000
\377\377\377\377\000\000\000\000\000IN\201\377\002\002\000\000\000\000\003\350\000\000\000d\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\002L\025\356\025\000\000\000\000L\022\337\316\000\000\000\000L\025\356\025\024\'\314\214\000\000\000\000\000\000\004\242\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\c\001\000\000\000\000\000\000\000\000\006\273"
a.sfattr.list[1].namelen = 195
a.sfattr.list[1].valuelen = 12
a.sfattr.list[1].root = 1
a.sfattr.list[1].secure = 1
a.sfattr.list[1].name =
"\377\377\377\000\000\000\000\000\000\000\000\000\006\000\000\373\340\000\001\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\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000S\001\000\f@\002SGI_ACL_FILE\000\000\000\005\000\000\000\001\377\377\377\377\000\a\000\000\000\000\000\002\000\000\004\346\000\a\000\000\000\000\000\004\377\377\377\377\000\a\000\000\000\000\000\020\377\377\377\377\000\a\000\000\000\000\000
\377\377\377\377\000\a\000\000\000IN\201\377\002\002\000\000\000\000\003\350\000\000\000d\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\002L\025\356\025"
a.sfattr.list[1].value = "\000\000\000\000L\022\337\316\000\000\000\000"
a.sfattr.list[2].namelen = 76
a.sfattr.list[2].valuelen = 21
a.sfattr.list[2].root = 1
a.sfattr.list[2].secure = 1
a.sfattr.list[2].name =
"\025\024\'\314\214\000\000\000\000\000\000\0046\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\c\001\000\000\000\000\000\000\000\000\006\273\303\f\377\377\377\377\000\000\000\000\000\000\000\000\000\a\000\000u@\000\001\000\000\000\000\000\000\000\000\000\000\000"
a.sfattr.list[2].value =
"\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
a.sfattr.list[3].namelen = 0
a.sfattr.list[3].valuelen = 0
a.sfattr.list[3].root = 0
a.sfattr.list[3].secure = 0
a.sfattr.list[4].namelen = 0
a.sfattr.list[4].valuelen = 0
a.sfattr.list[4].root = 0
a.sfattr.list[4].secure = 0
a.sfattr.list[5].namelen = 0
a.sfattr.list[5].valuelen = 0
a.sfattr.list[5].root = 0
a.sfattr.list[5].secure = 0
a.sfattr.list[6].namelen = 0
a.sfattr.list[6].valuelen = 0
a.sfattr.list[6].root = 0
a.sfattr.list[6].secure = 0
a.sfattr.list[7].namelen = 0
a.sfattr.list[7].valuelen = 0
a.sfattr.list[7].root = 0
a.sfattr.list[7].secure = 0
a.sfattr.list[8].namelen = 0
a.sfattr.list[8].valuelen = 0
a.sfattr.list[8].root = 0
a.sfattr.list[8].secure = 0
a.sfattr.list[9].namelen = 0
a.sfattr.list[9].valuelen = 0
a.sfattr.list[9].root = 0
a.sfattr.list[9].secure = 0
a.sfattr.list[10].namelen = 0
a.sfattr.list[10].valuelen = 0
a.sfattr.list[10].root = 0
a.sfattr.list[10].secure = 0
a.sfattr.list[11].namelen = 0
a.sfattr.list[11].valuelen = 83
a.sfattr.list[11].root = 0
a.sfattr.list[11].secure = 0
a.sfattr.list[11].value =
"\000\f@\002SGI_ACL_FILE\000\000\000\005\000\000\000\001\377\377\377\377\000\a\000\000\000\000\000\002\000\000\004\346\000\a\000\000\000\000\000\004\377\377\377\377\000\a\000\000\000\000\000\020\377\377\377\377\000\a\000\000\000\000\000
\377\377\377\377\000\a\000\000\000IN"
a.sfattr.list[12].namelen = 129
a.sfattr.list[12].valuelen = 255
a.sfattr.list[12].root = 1
a.sfattr.list[12].secure = 0
a.sfattr.list[12].name =
"\002\000\000\000\000\003\350\000\000\000d\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\002L\025\356\025\000\000\000\000L\022\337\316\000\000\000\000L\025\356\025\0247\017{\000\000\000\000\000\000$2\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\001\000\000\c\001\000\000\000\000\000\000\000\000\006\273\303\f\377\377\377\377\000\000\000\000\000\000\000\000\000\001\003\350y\240\000\003\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
a.sfattr.list[12].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\000\000S\001\000\f@\002SGI_ACL_FILE\000\000\000\005\000\000\000\001\377\377\377\377\000\a\000\000\000\000\000\002\000\000\004\346\000\a\000\000\000\000\000\004\377\377\377\377\000\a\000\000\000\000\000\020\377\377\377\377\000\a\000\000\000\000\000
\377\377\377\377\000\a\000\000\000IN\201\377\002\002\000\000\000\000\003\350\000\000\000d\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\002L\025\356\025\000\000\000\000L\022\337\316\000\000\000\000L\025\356\025\024FR\242\000\000\000\000\000\000\031\216\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\001\000\000\c\001\000\000\000\000\000\000\000\000\006\273\303\f\377\377\377\377\000\000\000\000\000\000\000\000\000\002\003;
\365\000\000\002\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
a.sfattr.list[13].namelen = 0
a.sfattr.list[13].valuelen = 0
a.sfattr.list[13].root = 0
a.sfattr.list[13].secure = 0
a.sfattr.list[14].namelen = 0
a.sfattr.list[14].valuelen = 0
a.sfattr.list[14].root = 0
a.sfattr.list[14].secure = 0
a.sfattr.list[15].namelen = 0
a.sfattr.list[15].valuelen = 0
a.sfattr.list[15].root = 0
a.sfattr.list[15].secure = 0
a.sfattr.list[16].namelen = 0
a.sfattr.list[16].valuelen = 0
a.sfattr.list[16].root = 0
a.sfattr.list[16].secure = 0
a.sfattr.list[17].namelen = 0
a.sfattr.list[17].valuelen = 0
a.sfattr.list[17].root = 0
a.sfattr.list[17].secure = 0
a.sfattr.list[18].namelen = 0
a.sfattr.list[18].valuelen = 0
a.sfattr.list[18].root = 0
a.sfattr.list[18].secure = 0
a.sfattr.list[19].namelen = 0
a.sfattr.list[19].valuelen = 0
a.sfattr.list[19].root = 0
a.sfattr.list[19].secure = 0
a.sfattr.list[20].namelen = 0
a.sfattr.list[20].valuelen = 0
a.sfattr.list[20].root = 0
a.sfattr.list[20].secure = 0
a.sfattr.list[21].namelen = 0
a.sfattr.list[21].valuelen = 0
a.sfattr.list[21].root = 0
a.sfattr.list[21].secure = 0
a.sfattr.list[22].namelen = 0
a.sfattr.list[22].valuelen = 0
a.sfattr.list[22].root = 0
a.sfattr.list[22].secure = 0
a.sfattr.list[23].namelen = 0
a.sfattr.list[23].valuelen = 0
a.sfattr.list[23].root = 0
a.sfattr.list[23].secure = 0
a.sfattr.list[24].namelen = 0
a.sfattr.list[24].valuelen = 0
a.sfattr.list[24].root = 0
a.sfattr.list[24].secure = 0
a.sfattr.list[25].namelen = 0
a.sfattr.list[25].valuelen = 0
a.sfattr.list[25].root = 0
a.sfattr.list[25].secure = 0
a.sfattr.list[26].namelen = 0
a.sfattr.list[26].valuelen = 83
a.sfattr.list[26].root = 0
a.sfattr.list[26].secure = 0
a.sfattr.list[26].value =
"\000\f@\002SGI_ACL_FILE\000\000\000\005\000\000\000\001\377\377\377\377\000\a\000\000\000\000\000\002\000\000\004\346\000\a\000\000\000\000\000\004\377\377\377\377\000\a\000\000\000\000\000\020\377\377\377\377\000\a\000\000\000\000\000
\377\377\377\377\000\a\000\000\000IN"
a.sfattr.list[27].namelen = 129
a.sfattr.list[27].valuelen = 255
a.sfattr.list[27].root = 1
a.sfattr.list[27].secure = 0
a.sfattr.list[27].name =
"\002\000\000\000\000\003\350\000\000\000d\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\002L\025\356\025\000\000\000\000L\022\337\315\000\000\000\000L\025\356\025\024FR\242\000\000\000\000\000\000\021\234\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\001\000\000\c\001\000\000\000\000\000\000\000\000\006\273\303\f\377\377\377\377\000\000\000\000\000\000\000\000\000\003\003P5\200\000\002\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
a.sfattr.list[27].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\000\000S\001\000\f@\002SGI_ACL_FILE\000\000\000\005\000\000\000\001\377\377\377\377\000\a\000\000\000\000\000\002\000\000\004\346\000\a\000\000\000\000\000\004\377\377\377\377\000\a\000\000\000\000\000\020\377\377\377\377\000\a\000\000\000\000\000
\377\377\377\377\000\a\000\000\000\000\000\000\000\000\000\000\000\361\017\000\000\000\000\000\000\020\360s\001\000\000\000\000\310t\251I\300\177\000\000\020\360s\001\000\000\000\000\2000t\001\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\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\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
a.sfattr.list[28].namelen = 0
a.sfattr.list[28].valuelen = 0
a.sfattr.list[28].root = 0
a.sfattr.list[28].secure = 0
a.sfattr.list[29].namelen = 0
a.sfattr.list[29].valuelen = 0
a.sfattr.list[29].root = 0
a.sfattr.list[29].secure = 0
a.sfattr.list[30].namelen = 0
a.sfattr.list[30].valuelen = 0
a.sfattr.list[30].root = 0
a.sfattr.list[30].secure = 0
a.sfattr.list[31].namelen = 0
a.sfattr.list[31].valuelen = 0
a.sfattr.list[31].root = 0
a.sfattr.list[31].secure = 0
a.sfattr.list[32].namelen = 0
a.sfattr.list[32].valuelen = 0
a.sfattr.list[32].root = 0
a.sfattr.list[32].secure = 0
a.sfattr.list[33].namelen = 0
a.sfattr.list[33].valuelen = 0
a.sfattr.list[33].root = 0
a.sfattr.list[33].secure = 0
a.sfattr.list[34].namelen = 0
a.sfattr.list[34].valuelen = 0
a.sfattr.list[34].root = 0
a.sfattr.list[34].secure = 0
a.sfattr.list[35].namelen = 0
a.sfattr.list[35].valuelen = 0
a.sfattr.list[35].root = 0
a.sfattr.list[35].secure = 0
a.sfattr.list[36].namelen = 0
a.sfattr.list[36].valuelen = 0
a.sfattr.list[36].root = 0
a.sfattr.list[36].secure = 0
a.sfattr.list[37].namelen = 0
a.sfattr.list[37].valuelen = 0
a.sfattr.list[37].root = 0
a.sfattr.list[37].secure = 0
a.sfattr.list[38].namelen = 0
a.sfattr.list[38].valuelen = 0
a.sfattr.list[38].root = 0
a.sfattr.list[38].secure = 0
a.sfattr.list[39].namelen = 0
a.sfattr.list[39].valuelen = 0
a.sfattr.list[39].root = 0
a.sfattr.list[39].secure = 0
> > [125903.343791] Pid: 17696, comm: ls Not tainted
> > 2.6.31.12-0.2-desktop #1
>
> That's getting a bit old now.
It's the most actual for openSUSE 11.2, which is the actual release.
Well, 11.3 should land on July 15...
> This kernel does not have any of the swap extent guards we added to
> avoid fsr corrupting inodes with attribute forks, and the above
> corruption report and the repair output look exactly like I saw when
> intentionally corrupting inodes with xfs_fsr.
>
> Hmmmm - do you run xfs_fsr? The errors reported and the corrutpion
> above are exactly what I'd expect from the swap extent bugs we fixed
> a while back....
Yes, xfs_fsdr was running. Disabled it now, and compiled and changed to
kernel 2.6.34 now. Hope that's OK ;-)
> I'll take a look.
Thank you!
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31
// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-07-01 8:22 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-27 1:10 WARNING xfsdump [still] Cannot allocate memory for list of [root|non-root] attributes for nondir ino xxyz Linda A. Walsh
2010-06-28 2:27 ` Dave Chinner
2010-06-29 22:33 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) Linda Walsh
2010-06-29 23:25 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ " Dave Chinner
2010-06-29 23:55 ` Michael Weissenbacher
2010-06-30 0:42 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ " Linda A. Walsh
2010-06-30 1:16 ` Dave Chinner
2010-06-30 2:45 ` Linda A. Walsh
2010-07-01 23:58 ` Dave Chinner
2010-07-07 3:18 ` Linda A. Walsh
2010-07-07 5:56 ` Linda Walsh
2010-07-07 6:36 ` Dave Chinner
2010-07-07 9:30 ` Linda A. Walsh
2010-07-07 21:01 ` Linda Walsh
2010-06-30 0:01 ` Linda A. Walsh
2010-06-30 1:06 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ " Dave Chinner
2010-06-30 1:52 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ " Linda A. Walsh
2010-06-30 21:01 ` Stan Hoeppner
2010-07-07 21:40 ` utf-8' chars from Winxp machine may be problem related (was Re: xfs file system in process of becoming corrupt; though xfs_repair...) Linda A. Walsh
2010-07-07 23:40 ` Stan Hoeppner
2010-07-08 0:38 ` Linda A. Walsh
2010-06-30 18:25 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) Michael Monnerie
2010-06-30 23:30 ` rsync and corrupt inodes (was xfs_dump problem) Dave Chinner
2010-07-01 8:25 ` Michael Monnerie [this message]
2010-07-02 2:42 ` Dave Chinner
2010-07-02 6:21 ` Michael Monnerie
2010-07-04 22:53 ` Dave Chinner
2010-07-12 11:28 ` Michael Monnerie
2010-07-07 21:56 ` Linda Walsh
-- strict thread matches above, loose matches on Subject: below --
2010-07-15 20:58 Michael Monnerie
2010-07-15 22:57 ` Dave Chinner
2010-07-16 14:17 ` Michael Monnerie
2010-07-16 14:40 ` 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=201007011025.04391@zmi.at \
--to=michael.monnerie@is.it-management.at \
--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