* WARNING xfsdump [still] Cannot allocate memory for list of [root|non-root] attributes for nondir ino xxyz @ 2010-06-27 1:10 Linda A. Walsh 2010-06-28 2:27 ` Dave Chinner 0 siblings, 1 reply; 29+ messages in thread From: Linda A. Walsh @ 2010-06-27 1:10 UTC (permalink / raw) To: xfs-oss FWIW -- that bug I mentioned a few weeks back that I thought was gone in the latest CVS of xfsdump -- isn't. It seems less frequent (maybe external attributes have been getting slow weeded out as they fail -- if it is random). What's 'unique' about this dump -- I just copied from one partition to another, to resize the first, and this is on the copy back. I.e. Stuff that xfs-restore just wrote has problems being read. First problem was about 30 minutes into the 'copy' Then about 2 more in the next half hour -- so not real often. This is with kernel 2.6.34. xfstools were downloaded a few weeks ago, so fairly recent. xfsdump: WARNING: could not get list of non-root attributes for nondir ino 2428439: Cannot allocate memory (12) in @ 108 MB/s, out @ 0.0 kB/s, 116 GB total, buffer 6% fullxfsdump: status at 02:25:06: 918808/2250704 files dumped, 54.3% data dumped, 1800 seconds elapsed in @ 14.0 MB/s, out @ 14.0 MB/s, 123 GB total, buffer 0% fullxfsdump: status at 02:30:06: 975579/2250704 files dumped, 57.6% data dumped, 2100 seconds elapsed in @ 0.0 kB/s, out @ 0.0 kB/s, 135 GB total, buffer 14% fullxfsdump: status at 02:35:07: 1062278/2250704 files dumped, 63.2% data dumped, 2401 seconds elapsed in @ 226 MB/s, out @ 157 MB/s, 152 GB total, buffer 91% fullxfsdump: status at 02:40:06: 1191037/2250704 files dumped, 71.5% data dumped, 2700 seconds elapsed in @ 0.0 kB/s, out @ 0.0 kB/s, 169 GB total, buffer 0% fullxfsdump: status at 02:45:06: 1321397/2250704 files dumped, 79.2% data dumped, 3000 seconds elapsed in @ 0.0 kB/s, out @ 120 MB/s, 176 GB total, buffer 30% full xfsdump: WARNING: could not get list of secure attributes for nondir ino 3929093: Cannot allocate memory (12) in @ 0.0 kB/s, out @ 118 MB/s, 177 GB total, buffer 7% full xfsdump: WARNING: could not get list of non-root attributes for nondir ino 3929095: Cannot allocate memory (12) _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: WARNING xfsdump [still] Cannot allocate memory for list of [root|non-root] attributes for nondir ino xxyz 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 0 siblings, 1 reply; 29+ messages in thread From: Dave Chinner @ 2010-06-28 2:27 UTC (permalink / raw) To: Linda A. Walsh; +Cc: xfs-oss On Sat, Jun 26, 2010 at 06:10:55PM -0700, Linda A. Walsh wrote: > > FWIW -- that bug I mentioned a few weeks back that I thought was > gone in the latest CVS > of xfsdump -- isn't. > > It seems less frequent (maybe external attributes have been getting > slow weeded out as > they fail -- if it is random). > > What's 'unique' about this dump -- I just copied from one partition > to another, to resize the first, > and this is on the copy back. > > I.e. Stuff that xfs-restore just wrote has problems being read. > > First problem was about 30 minutes into the 'copy' > > Then about 2 more in the next half hour -- so not real often. > > This is with kernel 2.6.34. > > xfstools were downloaded a few weeks ago, so fairly recent. > > xfsdump: WARNING: could not get list of non-root attributes for > nondir ino 2428439: Cannot allocate memory (12) > in @ 108 MB/s, out @ 0.0 kB/s, 116 GB total, buffer 6% > fullxfsdump: status at 02:25:06: 918808/2250704 files dumped, 54.3% > data dumped, 1800 seconds elapsed > in @ 14.0 MB/s, out @ 14.0 MB/s, 123 GB total, buffer 0% > fullxfsdump: status at 02:30:06: 975579/2250704 files dumped, 57.6% > data dumped, 2100 seconds elapsed > in @ 0.0 kB/s, out @ 0.0 kB/s, 135 GB total, buffer 14% > fullxfsdump: status at 02:35:07: 1062278/2250704 files dumped, 63.2% > data dumped, 2401 seconds elapsed > in @ 226 MB/s, out @ 157 MB/s, 152 GB total, buffer 91% > fullxfsdump: status at 02:40:06: 1191037/2250704 files dumped, 71.5% > data dumped, 2700 seconds elapsed > in @ 0.0 kB/s, out @ 0.0 kB/s, 169 GB total, buffer 0% > fullxfsdump: status at 02:45:06: 1321397/2250704 files dumped, 79.2% > data dumped, 3000 seconds elapsed > in @ 0.0 kB/s, out @ 120 MB/s, 176 GB total, buffer 30% full > > xfsdump: WARNING: could not get list of secure attributes for nondir > ino 3929093: Cannot allocate memory (12) > in @ 0.0 kB/s, out @ 118 MB/s, 177 GB total, buffer 7% full > > xfsdump: WARNING: could not get list of non-root attributes for > nondir ino 3929095: Cannot allocate memory (12) Can you get a list of all the attributes and their sizes on the inodes xfsdump is complaining about? Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 2010-06-28 2:27 ` Dave Chinner @ 2010-06-29 22:33 ` 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-30 18:25 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) Michael Monnerie 0 siblings, 2 replies; 29+ messages in thread From: Linda Walsh @ 2010-06-29 22:33 UTC (permalink / raw) To: Dave Chinner, xfs-oss Dave Chinner wrote: > Can you get a list of all the attributes and their sizes on the > inodes xfsdump is complaining about? > > Cheers, > > Dave. Wish I could...had a software problem that had me have to reuse the drive I just copied those examples from. But have another XFS problem that is much more reliably persistent. I don't know if they are at all related, but since I have this problem that's a bit "stuck", it's easier to "reproduce". Filesystem is one of my larger ones: Ishtar:/Torrents> 'df' -T --sync . Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/dm-7 xfs 6442319744 2305631080 4136688664 36% /Torrents Ishtar:/Torrents> 'df' -iT --sync . Filesystem Type Inodes IUsed IFree IUse% Mounted on /dev/dm-7 xfs 1288490112 34313 1288455799 1% /Torrents I have 3 files that developed 'bugs' in them in 3 separate directories. Oddly, they were they were 3 copies of the same 3 files. Very Odd. Symptom is from ls: --------------------------------------------------------------------------------------------------- Ishtar:/Torrents> 'ls' -ni bad* ls: cannot access bad/30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory ls: cannot access bad/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory ls: cannot access bad/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory bad: total 0 2359101 ?????????? ? ? ? ? ? 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3 2354946 ?????????? ? ? ? ? ? 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3 2354949 ?????????? ? ? ? ? ? 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3 ls: cannot access bad2/30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory ls: cannot access bad2/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory ls: cannot access bad2/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory bad2: total 0 2220560 ?????????? ? ? ? ? ? 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3 2220561 ?????????? ? ? ? ? ? 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3 2218302 ?????????? ? ? ? ? ? 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3 ls: cannot access bad3/30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory ls: cannot access bad3/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory ls: cannot access bad3/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory bad3: total 0 2218295 ?????????? ? ? ? ? ? 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3 2218296 ?????????? ? ? ? ? ? 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3 2218297 ?????????? ? ? ? ? ? 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3 --------------------------------------------------------------------------------------------------- The file system, labeled 'Torrents' is layered on a lvm base (I'm not convinced that lvm is as reliable as physical partitions at this point, which is why I mention it). It's a 'live' file system. What info do you want me to dump from it? I'm dumping the files from it now, so I can try to remake the file system. The problem is 'spreading' to "new" files. Basically, any file that is being written to now, seems to be in danger of becoming inaccessible. Also, FWIW -- I did unmount the file system and run xfs_repair. It finds no problems -- so why are these files not accessible? Ideas? Next steps? Thanks! Linda _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ (was xfs_dump problem...) 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 ` Dave Chinner 2010-06-29 23:55 ` Michael Weissenbacher 2010-06-30 0:01 ` 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 1 sibling, 2 replies; 29+ messages in thread From: Dave Chinner @ 2010-06-29 23:25 UTC (permalink / raw) To: Linda Walsh; +Cc: xfs-oss On Tue, Jun 29, 2010 at 03:33:02PM -0700, Linda Walsh wrote: > Dave Chinner wrote: > >Can you get a list of all the attributes and their sizes on the > >inodes xfsdump is complaining about? > > > >Cheers, > > > >Dave. > Wish I could...had a software problem that had me have to reuse the > drive I just copied those examples from. > > But have another XFS problem that is much more reliably persistent. > I don't know if they are at all related, but since I have this problem > that's a bit "stuck", it's easier to "reproduce". > > Filesystem is one of my larger ones: > > Ishtar:/Torrents> 'df' -T --sync . > Filesystem Type 1K-blocks Used Available Use% Mounted on > /dev/dm-7 xfs 6442319744 2305631080 4136688664 36% /Torrents > Ishtar:/Torrents> 'df' -iT --sync . > Filesystem Type Inodes IUsed IFree IUse% Mounted on > /dev/dm-7 xfs 1288490112 34313 1288455799 1% /Torrents > > I have 3 files that developed 'bugs' in them in 3 separate > directories. Oddly, they were they were 3 copies of the same 3 > files. Very Odd. > > Symptom is from ls: > --------------------------------------------------------------------------------------------------- > Ishtar:/Torrents> 'ls' -ni bad* ls: cannot access bad/30-Omoide > to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory > ls: cannot access bad/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory > ls: cannot access bad/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory > bad: > total 0 > 2359101 ?????????? ? ? ? ? ? 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3 > 2354946 ?????????? ? ? ? ? ? 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3 > 2354949 ?????????? ? ? ? ? ? 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3 > ls: cannot access bad2/30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory > ls: cannot access bad2/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory > ls: cannot access bad2/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory Those file names have a weird character in them - are you sure that the terminal supports that character set and is not mangling it and hence not matching what is actually stored on disk? > The file system, labeled 'Torrents' is layered on a lvm base (I'm not convinced that > lvm is as reliable as physical partitions at this point, which is why I mention it). > > It's a 'live' file system. What info do you want me to dump from it? > > I'm dumping the files from it now, so I can try to remake the file system. > > The problem is 'spreading' to "new" files. Basically, any file that is being written to > now, seems to be in danger of becoming inaccessible. Do those "new" files have the same strange characters in them? > Also, FWIW -- I did unmount the file system and run xfs_repair. It > finds no problems -- so why are these files not accessible? If there are no problems reported by repair, then I suspect that it's a terminal level problem... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ (was xfs_dump problem...) 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 0:01 ` Linda A. Walsh 1 sibling, 1 reply; 29+ messages in thread From: Michael Weissenbacher @ 2010-06-29 23:55 UTC (permalink / raw) To: xfs Hi! >> 2359101 ?????????? ? ? ? ? ? 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3 >> 2354946 ?????????? ? ? ? ? ? 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3 >> 2354949 ?????????? ? ? ? ? ? 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3 >> ls: cannot access bad2/30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory >> ls: cannot access bad2/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory >> ls: cannot access bad2/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory > > ... > > If there are no problems reported by repair, then I suspect that > it's a terminal level problem... > Looking at this i remember having similar problems when my filesystems was mounted with inode64 before and after i left out that parameter. So Linda, could you re-try mounting the fs with "inode64". cheers, Michael _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 2010-06-29 23:55 ` Michael Weissenbacher @ 2010-06-30 0:42 ` Linda A. Walsh 2010-06-30 1:16 ` Dave Chinner 0 siblings, 1 reply; 29+ messages in thread From: Linda A. Walsh @ 2010-06-30 0:42 UTC (permalink / raw) To: Michael Weissenbacher, xfs-oss Michael Weissenbacher wrote: > Hi! >>> 2359101 ?????????? ? ? ? ? ? 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3 >>> 2354946 ?????????? ? ? ? ? ? 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3 >>> 2354949 ?????????? ? ? ? ? ? 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3 >>> ls: cannot access bad2/30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory >>> ls: cannot access bad2/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory >>> ls: cannot access bad2/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory >> ... >> >> If there are no problems reported by repair, then I suspect that >> it's a terminal level problem... >> > Looking at this i remember having similar problems when my filesystems > was mounted with inode64 before and after i left out that parameter. So > Linda, could you re-try mounting the fs with "inode64". ---- I ran into that before as well -- already tried Notice the listing you see is the output of "ls -in". Those numbers are the inodes. ...HEY, wait. When do you need 64-bit inodes? The dump size said it was: xfsdump: estimated dump size: 2360915740992 bytes It's getting right near to overflowing a 32-bit integer. Do I need >32 bit inodes if the filesystem size is > 2T? I'm guessing the file system just recently passed the 2G mark. Note -- I DID try the inode64 mount option -- it made no difference. But if you need 64-bit inodes for file systems > 2T file systems, then shouldn't I have gotten some error rather than it eating files for lunch? The inode numbers themselves, are not even close to being over 32bits. Sigh... _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 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 0 siblings, 1 reply; 29+ messages in thread From: Dave Chinner @ 2010-06-30 1:16 UTC (permalink / raw) To: Linda A. Walsh; +Cc: Michael Weissenbacher, xfs-oss On Tue, Jun 29, 2010 at 05:42:02PM -0700, Linda A. Walsh wrote: > Do I need >32 bit inodes if the filesystem size is > 2T? No. inode64 is recommended for multi-terabyte filesystems, but is not mandatory. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 2010-06-30 1:16 ` Dave Chinner @ 2010-06-30 2:45 ` Linda A. Walsh 2010-07-01 23:58 ` Dave Chinner 0 siblings, 1 reply; 29+ messages in thread From: Linda A. Walsh @ 2010-06-30 2:45 UTC (permalink / raw) To: xfs-oss To make matters more interesting -- xfsdump can't access a couple of files and a directory or two. It thinks they are 'stale NFS handles' (I'm not running any NFS file systems). in @ 0.0 kB/s, out @ 0.0 kB/s, 0.0 kB total, buffer 0% fullxfsdump: WARNING: unable to open directory: ino 2082342: Stale NFS file handle xfsdump: WARNING: unable to open directory: ino 2082343: Stale NFS file handle in @ 4079 kB/s, out @ 4079 kB/s, 2040 kB total, buffer 0% fullxfsdump: dumping non-directory files in @ 68.0 MB/s, out @ 68.0 MB/s, 1209 GB total, buffer 0% fullll in @ 107 MB/s, out @ 105 MB/s, 2200 GB total, buffer 0% fullxfsdump: ending media file xfsdump: media file size 2362017678616 bytes xfsdump: dump size (non-dir files) : 2361953613176 bytes xfsdump: dump complete: 10926 seconds elapsed xfsdump: Dump Status: SUCCESS Running xfs_db on the file system (finished dumping) a block get returns: dir 1133368 block 0 extra leaf entry 5438b33d 79 dir 1133368 block 0 extra leaf entry 6624beba 71 dir 1133368 block 0 extra leaf entry 6d832f88 69 dir 1133368 block 0 extra leaf entry e6279e2d 80 dir ino 1133368 missing leaf entry for e627de2d/80 dir ino 1133368 missing leaf entry for 7624beba/71 dir ino 1133368 missing leaf entry for 5418b33d/79 dir ino 1133368 missing leaf entry for 6d832f80/69 dir 1134347 block 0 extra leaf entry 3907754f 4e dir 1134347 block 0 extra leaf entry 3cae5257 47 dir 1134347 block 0 extra leaf entry 6e3a4cfb 40 dir ino 1134347 missing leaf entry for 6e38ccfb/40 dir ino 1134347 missing leaf entry for 3905f54f/4e dir ino 1134347 missing leaf entry for 3cacd257/47 dir 1149453 block 0 extra leaf entry 190f789f 7d dir ino 1149453 missing leaf entry for 190b78df/7d dir 1193988 block 0 extra leaf entry 8f2b7b0c 80 dir ino 1193988 missing leaf entry for 8d2b7b0c/80 dir 2098474 block 0 extra leaf entry 891d210e b5 dir ino 2098474 missing leaf entry for 891d200f/b5 dir 2103050 block 0 extra leaf entry 3c8b96be 79 dir ino 2103050 missing leaf entry for 3c8b96ae/79 dir 2106377 block 0 extra leaf entry 6554830e 185 dir 2106377 block 0 extra leaf entry 8265fcda 173 dir 2106377 block 0 extra leaf entry b251fcda 17f dir 2106377 block 0 extra leaf entry b687730b 179 dir ino 2106377 missing leaf entry for 8265fcd2/173 dir ino 2106377 missing leaf entry for b251fcd2/17f dir ino 2106377 missing leaf entry for b687734b/179 dir ino 2106377 missing leaf entry for 6554c31e/185 dir 2107395 block 0 extra leaf entry 207fea65 ff dir 2107395 block 0 extra leaf entry dd1d75a2 f8 dir ino 2107395 missing leaf entry for df1d75a2/f8 dir ino 2107395 missing leaf entry for 206fea65/ff dir 2215937 block 0 extra leaf entry 1d5bcd6d 3a dir 2215937 block 0 extra leaf entry 9c82da3c 9c dir 2215937 block 0 extra leaf entry ff88d238 a4 dir ino 2215937 missing leaf entry for 1f5bcd6d/3a dir ino 2215937 missing leaf entry for fd88d238/a4 dir ino 2215937 missing leaf entry for 9e82da3c/9c dir 2218278 block 0 extra leaf entry 1d5bcd6d 3a dir 2218278 block 0 extra leaf entry 9c82da3c 9c dir 2218278 block 0 extra leaf entry ff88d238 a4 dir ino 2218278 missing leaf entry for 1f5bcd6d/3a dir ino 2218278 missing leaf entry for fd88d238/a4 dir ino 2218278 missing leaf entry for 9e82da3c/9c dir 2241309 block 0 extra leaf entry 51ae209 39 dir 2241309 block 0 extra leaf entry b5c3baca 32 dir ino 2241309 missing leaf entry for 5186209/39 dir ino 2241309 missing leaf entry for b5c13aca/32 dir 2291983 block 0 extra leaf entry 16650e73 117 dir 2291983 block 0 extra leaf entry 355a317c 112 dir 2291983 block 0 extra leaf entry 47464246 ee dir 2291983 block 0 extra leaf entry 620ec6fb 109 dir 2291983 block 0 extra leaf entry 62170366 e7 dir 2291983 block 0 extra leaf entry 73c17bba 10d dir 2291983 block 0 extra leaf entry 747a8790 e2 dir 2291983 block 0 extra leaf entry 894504e3 ff dir 2291983 block 0 extra leaf entry b17d4203 11c dir 2291983 block 0 extra leaf entry d12c165b 105 dir 2291983 block 0 extra leaf entry d33f483d fb dir 2291983 block 0 extra leaf entry e28ebb3b f2 dir 2291983 block 0 extra leaf entry f9f9b6d1 f6 dir ino 2291983 missing leaf entry for 8b4504e3/ff dir ino 2291983 missing leaf entry for d33f48ad/fb dir ino 2291983 missing leaf entry for 375a317c/112 dir ino 2291983 missing leaf entry for e9f9bed1/f6 dir ino 2291983 missing leaf entry for 45464246/ee dir ino 2291983 missing leaf entry for 71c17bba/10d dir ino 2291983 missing leaf entry for b13d4203/11c dir ino 2291983 missing leaf entry for 745a8790/e2 dir ino 2291983 missing leaf entry for 16650e63/117 dir ino 2291983 missing leaf entry for e21f0366/e7 dir ino 2291983 missing leaf entry for e08ebb2b/f2 dir ino 2291983 missing leaf entry for d12896db/105 dir ino 2291983 missing leaf entry for 620ec6eb/109 xfs_repair -n now shows: Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 2 - agno = 1 - agno = 0 - agno = 5 - agno = 4 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... entry "10 Otome ha DO MY BEST desho¿ (off vocal).flac" (ino 2359102) in dir 1133368 is a duplicate name, would junk entry entry "06 Otome ha DO MY BEST desho¿ Otome ver..flac" (ino 2359100) in dir 1133368 is a duplicate name, would junk entry entry "05 Otome ha DO MY BEST desho¿ Hime ver..flac" (ino 2359099) in dir 1133368 is a duplicate name, would junk entry entry "04 Otome ha DO MY BEST desho¿ 2007ver..flac" (ino 2359086) in dir 1133368 is a duplicate name, would junk entry entry "04 Finality blue «instrumental».flac" (ino 2220801) in dir 1134347 is a duplicate name, would junk entry entry "06 Koko ni Atta ne «instrumental».flac" (ino 2220800) in dir 1134347 is a duplicate name, would junk entry entry "05 Heart All Green «instrumental».flac" (ino 2359103) in dir 1134347 is a duplicate name, would junk entry entry "01_Tenkai Hen Josô e no Zensô Kyoku.mp3" (ino 2359093) in dir 1149453 is a duplicate name, would junk entry entry "01 Träumerei.flac" (ino 2359098) in dir 1193988 is a duplicate name, would junk entry entry "16 - Pretty Guardian Sailor Moon - Kiss!² Bang!².ogg" (ino 2359097) in dir 2098474 is a duplicate name, would junk entry entry "03 Broken MÖBIUS.ogg" (ino 2359094) in dir 2103050 is a duplicate name, would junk entry entry "14 - Broken MÖBIUS Henkei A.ogg" (ino 2359095) in dir 2106377 is a duplicate name, would junk entry entry "27 - Shin·Henshin Sailormoon.ogg" (ino 2359092) in dir 2106377 is a duplicate name, would junk entry entry "19 - Broken MÖBIUS Henkei B.ogg" (ino 2359088) in dir 2106377 is a duplicate name, would junk entry entry "06 - GURU·GURU·GURA.ogg" (ino 2359089) in dir 2106377 is a duplicate name, would junk entry entry "35 Ankoku no Uranai Noshi · Lilith.ogg" (ino 2359091) in dir 2107395 is a duplicate name, would junk entry entry "17 Kaguya Shima·Mukashi Mono Gatarii.ogg" (ino 2359087) in dir 2107395 is a duplicate name, would junk entry bad hash table for directory inode 2215937 (hash value mismatch): would rebuild bad hash table for directory inode 2218278 (hash value mismatch): would rebuild entry "03 Free and Dream «Instrumental».flac" (ino 2359090) in dir 2241309 is a duplicate name, would junk entry entry "04 Asu he -Sorairo no Tegami- «Instrumental».flac" (ino 2359096) in dir 2241309 is a duplicate name, would junk entry entry "18 Rafraîchissement.flac" (ino 2359085) in dir 2291983 is a duplicate name, would junk entry entry "17 Différent malgré la ressemblance.flac" (ino 2218273) in dir 2291983 is a duplicate name, would junk entry entry "09 Sincèrement.flac" (ino 2218271) in dir 2291983 is a duplicate name, would junk entry entry "15 Déjà Vu.flac" (ino 2218276) in dir 2291983 is a duplicate name, would junk entry entry "20 Fête d'école.flac" (ino 2218275) in dir 2291983 is a duplicate name, would junk entry entry "12 Péripétie.flac" (ino 2218270) in dir 2291983 is a duplicate name, would junk entry entry "27 Lieu de la bataille décisive.flac" (ino 2218272) in dir 2291983 is a duplicate name, would junk entry entry "06 Sérénité.flac" (ino 2218274) in dir 2291983 is a duplicate name, would junk entry entry "04 Tragédie.flac" (ino 2218266) in dir 2291983 is a duplicate name, would junk entry entry "25 Serment éternel.flac" (ino 2218268) in dir 2291983 is a duplicate name, would junk entry entry "16 Force étrange.flac" (ino 2218277) in dir 2291983 is a duplicate name, would junk entry entry "28 Manoeuvres secrètes.flac" (ino 2218269) in dir 2291983 is a duplicate name, would junk entry entry "26 Jours passés.flac" (ino 2218267) in dir 2291983 is a duplicate name, would junk entry - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 2218266, would move to lost+found disconnected inode 2218267, would move to lost+found disconnected inode 2218268, would move to lost+found disconnected inode 2218269, would move to lost+found disconnected inode 2218270, would move to lost+found disconnected inode 2218271, would move to lost+found disconnected inode 2218272, would move to lost+found disconnected inode 2218273, would move to lost+found disconnected inode 2218274, would move to lost+found disconnected inode 2218275, would move to lost+found disconnected inode 2218276, would move to lost+found disconnected inode 2218277, would move to lost+found disconnected inode 2220800, would move to lost+found disconnected inode 2220801, would move to lost+found disconnected inode 2359085, would move to lost+found disconnected inode 2359086, would move to lost+found disconnected inode 2359087, would move to lost+found disconnected inode 2359088, would move to lost+found disconnected inode 2359089, would move to lost+found disconnected inode 2359090, would move to lost+found disconnected inode 2359091, would move to lost+found disconnected inode 2359092, would move to lost+found disconnected inode 2359093, would move to lost+found disconnected inode 2359094, would move to lost+found disconnected inode 2359095, would move to lost+found disconnected inode 2359096, would move to lost+found disconnected inode 2359097, would move to lost+found disconnected inode 2359098, would move to lost+found disconnected inode 2359099, would move to lost+found disconnected inode 2359100, would move to lost+found disconnected inode 2359102, would move to lost+found disconnected inode 2359103, would move to lost+found Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. ------------- This isn't going to help to repair it though -- I repaired it this morning and it showed up as fine! Then all of the above happened today! It would appear that 2.6.34 might have some problems in it? -linda _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 2010-06-30 2:45 ` Linda A. Walsh @ 2010-07-01 23:58 ` Dave Chinner 2010-07-07 3:18 ` Linda A. Walsh 0 siblings, 1 reply; 29+ messages in thread From: Dave Chinner @ 2010-07-01 23:58 UTC (permalink / raw) To: Linda A. Walsh; +Cc: xfs-oss On Tue, Jun 29, 2010 at 07:45:21PM -0700, Linda A. Walsh wrote: > To make matters more interesting -- xfsdump can't access a couple of > files and a directory or two. > > It thinks they are 'stale NFS handles' (I'm not running any NFS file > systems). > > in @ 0.0 kB/s, out @ 0.0 kB/s, 0.0 kB total, buffer 0% fullxfsdump: WARNING: unable to open directory: ino 2082342: Stale NFS file handle > xfsdump: WARNING: unable to open directory: ino 2082343: Stale NFS file handle xfsdump uses the handle interfaces to open files direct from bulkstat information, and this is a typical error when bulkstat returns an inode and it is unlinked before dump opens the handle created from the bulkstat information. > in @ 4079 kB/s, out @ 4079 kB/s, 2040 kB total, buffer 0% fullxfsdump: dumping non-directory files > in @ 68.0 MB/s, out @ 68.0 MB/s, 1209 GB total, buffer 0% fullll > in @ 107 MB/s, out @ 105 MB/s, 2200 GB total, buffer 0% fullxfsdump: ending media file > xfsdump: media file size 2362017678616 bytes > xfsdump: dump size (non-dir files) : 2361953613176 bytes > xfsdump: dump complete: 10926 seconds elapsed > xfsdump: Dump Status: SUCCESS > > Running xfs_db on the file system (finished dumping) > a block get returns: Just a reminder - you can't trust xfs_db output on a live mounted filesystem.... > dir 1133368 block 0 extra leaf entry 5438b33d 79 > dir 1133368 block 0 extra leaf entry 6624beba 71 > dir 1133368 block 0 extra leaf entry 6d832f88 69 > dir 1133368 block 0 extra leaf entry e6279e2d 80 > dir ino 1133368 missing leaf entry for e627de2d/80 > dir ino 1133368 missing leaf entry for 7624beba/71 > dir ino 1133368 missing leaf entry for 5418b33d/79 > dir ino 1133368 missing leaf entry for 6d832f80/69 I'm not sure why the blockget thinks there's a extra entries in block 0 in the directory, but then says the entries for the same hash index are missing. I'd need a metadump of the filesystem to be able to look at it directly... > xfs_repair -n now shows: ..... > Phase 6 - check inode connectivity... > - traversing filesystem ... > entry "10 Otome ha DO MY BEST desho¿ (off vocal).flac" (ino 2359102) in dir 1133368 is a duplicate name, would junk entry > entry "06 Otome ha DO MY BEST desho¿ Otome ver..flac" (ino 2359100) in dir 1133368 is a duplicate name, would junk entry > entry "05 Otome ha DO MY BEST desho¿ Hime ver..flac" (ino 2359099) in dir 1133368 is a duplicate name, would junk entry > entry "04 Otome ha DO MY BEST desho¿ 2007ver..flac" (ino 2359086) in dir 1133368 is a duplicate name, would junk entry .... Every single filename has some special character in it. Of course, my question is why are there two copies of the same directory name? Was the file created twice? How did these files get created? If you just copy them, does the destination directory end up corrupted? > It would appear that 2.6.34 might have some problems in it? I don't think we changed anything at all directory related in XFS in 2.6.34 so I'm a little perplexed as to why this is suddenly all happening. Did these problems only show up when you updated to 2.6.34, or can you reproduce them on an older kernel? Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 2010-07-01 23:58 ` Dave Chinner @ 2010-07-07 3:18 ` Linda A. Walsh 2010-07-07 5:56 ` Linda Walsh 0 siblings, 1 reply; 29+ messages in thread From: Linda A. Walsh @ 2010-07-07 3:18 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs-oss Dave Chinner wrote: > I don't think we changed anything at all directory related in > XFS in 2.6.34 so I'm a little perplexed as to why this is suddenly > all happening. Did these problems only show up when you updated to > 2.6.34, or can you reproduce them on an older kernel? ---- I've not had a chance to check this. But have been running 2.6.34 for about 3+ weeks. Have had alot of changes on my sys, including adding disks -- resulting in ALOT of disk-disk copyies that I've mostly done with a "xfsdump|mbuffer|xfsrestore" pipe, though I've started using 'star' (handles acls & ext_attrs) with fewer errors than the pipe. However -- the biggie that was giving me the most problems is a disk with lots of 'foreign' names on it -- many of which have been getting stored via 'samba' from WinXP clients that don't speak very good UTF-8 (if at all). With WinXP, I had files that were undelete-able on Windows (explorer or shell) that I *could* delete, from linux because linux spoke UTF-8. Well now I have some similar files on linux -- they might have been stored in a weird character set -- ASCII and UTF-8 don't work to read them. They don't read as errors but nothing can read them. While it is "bothersome" that I can't read them, I would have expected that xfsdump/restore would have used character-set 'irrelevant' calls to dump/restore files just to circumvent these problems. At this point, I haven't yet stumbled onto how to address those files in linux in order to delete or rename them to a UTF-8 normalized form. At this point, I'm just guessing that this is the problem, but it's my best guess so far... Any ideas would be appreciated...will keep you posted. -linda p.s. (on top of things had file system problems that caused last week's email to evaporate! so anything that was sent to me was lost, though I could read through archives to find things that were sent to the list -- not the best use of time, though, I'm afraid...). _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 2010-07-07 3:18 ` Linda A. Walsh @ 2010-07-07 5:56 ` Linda Walsh 2010-07-07 6:36 ` Dave Chinner 0 siblings, 1 reply; 29+ messages in thread From: Linda Walsh @ 2010-07-07 5:56 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs-oss For what it's worth, my 'undeletable' files give every appearance of being 'plain' UTF-8 encoded file names. Wrote a perl script that looped through and used the 'bytes' pragma to look at the bytes. Looks like valid UTF-8. Also had it try to remove the files. Didn't work. Read 9 files 1: 2e >|. |< 2: 2e 2e >|.. |< 3: 42 6f 72 64 75 72 65 20 70 6f 69 6e 74 69 6c 6c >|Bordure pointill|< c3 a9 65 20 2d 20 42 6c 61 6e 63 2d 6e 6f 69 72 >|..e - Blanc-noir|< Unlink of "Bordure pointillée - Blanc-noir" failed: No such file or directory 4: 42 6f 72 64 75 72 65 20 70 6f 69 6e 74 69 6c 6c >|Bordure pointill|< c3 a9 65 20 2d 20 4e 6f 69 72 2d 62 6c 61 6e 63 >|..e - Noir-blanc|< Unlink of "Bordure pointillée - Noir-blanc" failed: No such file or directory 5: 43 61 64 72 65 20 63 65 6e 74 72 c3 a9 20 31 20 >|Cadre centr.. 1 |< 2d 20 42 61 73 65 >|- Base |< Unlink of "Cadre centré 1 - Base" failed: No such file or directory ....rest of output truncated. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 2010-07-07 5:56 ` Linda Walsh @ 2010-07-07 6:36 ` Dave Chinner 2010-07-07 9:30 ` Linda A. Walsh 0 siblings, 1 reply; 29+ messages in thread From: Dave Chinner @ 2010-07-07 6:36 UTC (permalink / raw) To: Linda Walsh; +Cc: xfs-oss On Tue, Jul 06, 2010 at 10:56:34PM -0700, Linda Walsh wrote: > For what it's worth, my 'undeletable' files give every appearance of > being 'plain' UTF-8 encoded file names. Wrote a perl script that looped > through and used the 'bytes' pragma to look at the bytes. Looks like > valid UTF-8. Also had it try to remove the files. Didn't work. Can you send me a link to a metadump image of the filesystem so I can look at the broken directories in detail? Cheers. Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 2010-07-07 6:36 ` Dave Chinner @ 2010-07-07 9:30 ` Linda A. Walsh 2010-07-07 21:01 ` Linda Walsh 0 siblings, 1 reply; 29+ messages in thread From: Linda A. Walsh @ 2010-07-07 9:30 UTC (permalink / raw) To: Dave Chinner, xfs-oss Dave Chinner wrote: > Can you send me a link to a metadump image of the filesystem so I can > look at the broken directories in detail? ---- I'll have to work on that -- right now I'm taking a copy and trying to delete everything off of it, so the meta copy, hopefully will have just the stuff that won't delete... (at least that's the theory)... BTW -- reviewing log files...there some stuff there that corresponds to not begin able to read files and metadata, though I don't know the exact runtime messages I was getting at the time: Jul 6 08:15:54 Ishtar kernel: [33919.157874] xfsdump: page allocation failure. order:4, mode:0x40d0 Jul 6 08:17:12 Ishtar kernel: [33997.243321] xfsdump: page allocation failure. order:4, mode:0x40d0 Jul 6 08:17:51 Ishtar kernel: [34036.405012] xfsdump: page allocation failure. order:4, mode:0x40d0 .... .... Jul 6 08:17:12 Ishtar kernel: [33997.243326] Pid: 5047, comm: xfsdump Not tainted 2.6.34T610-Vanilla #1 Jul 6 08:17:12 Ishtar kernel: [33997.243329] Call Trace: Jul 6 08:17:12 Ishtar kernel: [33997.243338] [<ffffffff810c24d6>] __alloc_pages_nodemask+0x5b6/0x6a0 Jul 6 08:17:12 Ishtar kernel: [33997.243343] [<ffffffff810c25d2>] __get_free_pages+0x12/0x50 Jul 6 08:17:12 Ishtar kernel: [33997.243349] [<ffffffff810f26d9>] __kmalloc+0x189/0x1e0 Jul 6 08:17:12 Ishtar kernel: [33997.243353] [<ffffffff8125b82e>] xfs_attrlist_by_handle+0xbe/0x130 Jul 6 08:17:12 Ishtar kernel: [33997.243358] [<ffffffff8125c6c9>] xfs_file_ioctl+0x5f9/0x980 Jul 6 08:17:12 Ishtar kernel: [33997.243364] [<ffffffff8158f4e1>] ? down_read+0x11/0x30 Jul 6 08:17:12 Ishtar kernel: [33997.243370] [<ffffffff8123276d>] ? xfs_iunlock+0xdd/0x130 Jul 6 08:17:12 Ishtar kernel: [33997.243374] [<ffffffff81250d05>] ? xfs_free_eofblocks+0xd5/0x260 Jul 6 08:17:12 Ishtar kernel: [33997.243379] [<ffffffff81107ca8>] vfs_ioctl+0x38/0xd0 Jul 6 08:17:12 Ishtar kernel: [33997.243382] [<ffffffff81107e7a>] do_vfs_ioctl+0x8a/0x5a0 Jul 6 08:17:12 Ishtar kernel: [33997.243387] [<ffffffff810fa40c>] ? __fput+0x19c/0x210 Jul 6 08:17:12 Ishtar kernel: [33997.243391] [<ffffffff81108411>] sys_ioctl+0x81/0xa0 Jul 6 08:17:12 Ishtar kernel: [33997.243396] [<ffffffff81002deb>] system_call_fastpath+0x16/0x1b Jul 6 08:17:12 Ishtar kernel: [33997.243398] Mem-Info: Jul 6 08:17:12 Ishtar kernel: [33997.243400] DMA per-cpu: Jul 6 08:17:12 Ishtar kernel: [33997.243402] CPU 0: hi: 0, btch: 1 usd: 0 Jul 6 08:17:12 Ishtar kernel: [33997.243405] CPU 1: hi: 0, btch: 1 usd: 0 Jul 6 08:17:12 Ishtar kernel: [33997.243407] CPU 2: hi: 0, btch: 1 usd: 0 Jul 6 08:17:12 Ishtar kernel: [33997.243409] CPU 3: hi: 0, btch: 1 usd: 0 Jul 6 08:17:12 Ishtar kernel: [33997.243411] DMA32 per-cpu: Jul 6 08:17:12 Ishtar kernel: [33997.243413] CPU 0: hi: 186, btch: 31 usd: 0 Jul 6 08:17:12 Ishtar kernel: [33997.243416] CPU 1: hi: 186, btch: 31 usd: 10 Jul 6 08:17:12 Ishtar kernel: [33997.243418] CPU 2: hi: 186, btch: 31 usd: 0 Jul 6 08:17:12 Ishtar kernel: [33997.243425] CPU 3: hi: 186, btch: 31 usd: 0 Jul 6 08:17:12 Ishtar kernel: [33997.243427] Normal per-cpu: Jul 6 08:17:12 Ishtar kernel: [33997.243431] CPU 0: hi: 186, btch: 31 usd: 12 Jul 6 08:17:12 Ishtar kernel: [33997.243435] CPU 1: hi: 186, btch: 31 usd: 36 Jul 6 08:17:12 Ishtar kernel: [33997.243439] CPU 2: hi: 186, btch: 31 usd: 15 Jul 6 08:17:12 Ishtar kernel: [33997.243443] CPU 3: hi: 186, btch: 31 usd: 0 Jul 6 08:17:12 Ishtar kernel: [33997.243451] active_anon:39844 inactive_anon:31818 isolated_anon:0 Jul 6 08:17:12 Ishtar kernel: [33997.243454] active_file:854853 inactive_file:4597578 isolated_file:44 Jul 6 08:17:12 Ishtar kernel: [33997.243457] unevictable:262348 dirty:348876 writeback:2 unstable:0 Jul 6 08:17:12 Ishtar kernel: [33997.243460] free:59942 slab_reclaimable:294751 slab_unreclaimable:26479 Jul 6 08:17:12 Ishtar kernel: [33997.243463] mapped:18561 shmem:6 pagetables:2966 bounce:0 Jul 6 08:17:12 Ishtar kernel: [33997.243473] DMA free:15868kB min:12kB low:12kB high:16kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15772kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Jul 6 08:17:12 Ishtar kernel: [33997.243491] lowmem_reserve[]: 0 2990 24200 24200 Jul 6 08:17:12 Ishtar kernel: [33997.243504] DMA32 free:199276kB min:2456kB low:3068kB high:3684kB active_anon:48kB inactive_anon:2672kB active_file:195724kB inactive_file:1726428kB unevictable:55768kB isolated(anon):0kB isolated(file):0kB present:3062596kB mlocked:55768kB dirty:107612kB writeback:0kB mapped:6352kB shmem:0kB slab_reclaimable:509064kB slab_unreclaimable:22184kB kernel_stack:64kB pagetables:444kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Jul 6 08:17:12 Ishtar kernel: [33997.243524] lowmem_reserve[]: 0 0 21210 21210 Jul 6 08:17:12 Ishtar kernel: [33997.243537] Normal free:24624kB min:17440kB low:21800kB high:26160kB active_anon:159328kB inactive_anon:124600kB active_file:3223688kB inactive_file:16663884kB unevictable:993624kB isolated(anon):0kB isolated(file):176kB present:21719040kB mlocked:993624kB dirty:1287892kB writeback:8kB mapped:67892kB shmem:24kB slab_reclaimable:669940kB slab_unreclaimable:83732kB kernel_stack:3320kB pagetables:11420kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Jul 6 08:17:12 Ishtar kernel: [33997.243557] lowmem_reserve[]: 0 0 0 0 Jul 6 08:17:12 Ishtar kernel: [33997.243565] DMA: 1*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15868kB Jul 6 08:17:12 Ishtar kernel: [33997.243583] DMA32: 26095*4kB 10064*8kB 798*16kB 52*32kB 3*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 199516kB Jul 6 08:17:12 Ishtar kernel: [33997.243602] Normal: 5486*4kB 0*8kB 0*16kB 4*32kB 2*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 24376kB Jul 6 08:17:12 Ishtar kernel: [33997.243621] 5462983 total pagecache pages Jul 6 08:17:12 Ishtar kernel: [33997.243625] 10294 pages in swap cache Jul 6 08:17:12 Ishtar kernel: [33997.243629] Swap cache stats: add 455795, delete 445501, find 338025/357649 Jul 6 08:17:12 Ishtar kernel: [33997.243633] Free swap = 8151268kB Jul 6 08:17:12 Ishtar kernel: [33997.243637] Total swap = 8393924kB Jul 6 08:17:12 Ishtar kernel: [33997.345120] 6291455 pages RAM Jul 6 08:17:12 Ishtar kernel: [33997.345122] 104293 pages reserved Jul 6 08:17:12 Ishtar kernel: [33997.345124] 3464575 pages shared Jul 6 08:17:12 Ishtar kernel: [33997.345125] 2682993 pages non-shared Jul 6 08:17:51 Ishtar kernel: [34036.405017] Pid: 5047, comm: xfsdump Not tainted 2.6.34T610-Vanilla #1 Jul 6 08:17:51 Ishtar kernel: [34036.405020] Call Trace: Jul 6 08:17:51 Ishtar kernel: [34036.405029] [<ffffffff810c24d6>] __alloc_pages_nodemask+0x5b6/0x6a0 Jul 6 08:17:51 Ishtar kernel: [34036.405034] [<ffffffff810c25d2>] __get_free_pages+0x12/0x50 Jul 6 08:17:51 Ishtar kernel: [34036.405040] [<ffffffff810f26d9>] __kmalloc+0x189/0x1e0 Jul 6 08:17:51 Ishtar kernel: [34036.405044] [<ffffffff8125b82e>] xfs_attrlist_by_handle+0xbe/0x130 Jul 6 08:17:51 Ishtar kernel: [34036.405048] [<ffffffff8125c6c9>] xfs_file_ioctl+0x5f9/0x980 Jul 6 08:17:51 Ishtar kernel: [34036.405055] [<ffffffff8158f4e1>] ? down_read+0x11/0x30 Jul 6 08:17:51 Ishtar kernel: [34036.405060] [<ffffffff8123276d>] ? xfs_iunlock+0xdd/0x130 Jul 6 08:17:51 Ishtar kernel: [34036.405065] [<ffffffff81250d05>] ? xfs_free_eofblocks+0xd5/0x260 Jul 6 08:17:51 Ishtar kernel: [34036.405070] [<ffffffff81107ca8>] vfs_ioctl+0x38/0xd0 Jul 6 08:17:51 Ishtar kernel: [34036.405073] [<ffffffff81107e7a>] do_vfs_ioctl+0x8a/0x5a0 Jul 6 08:17:51 Ishtar kernel: [34036.405084] [<ffffffff810fa40c>] ? __fput+0x19c/0x210 Jul 6 08:17:51 Ishtar kernel: [34036.405087] [<ffffffff81108411>] sys_ioctl+0x81/0xa0 Jul 6 08:17:51 Ishtar kernel: [34036.405093] [<ffffffff81002deb>] system_call_fastpath+0x16/0x1b Jul 6 08:17:51 Ishtar kernel: [34036.405095] Mem-Info: Jul 6 08:17:51 Ishtar kernel: [34036.405097] DMA per-cpu: Jul 6 08:17:51 Ishtar kernel: [34036.405099] CPU 0: hi: 0, btch: 1 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405101] CPU 1: hi: 0, btch: 1 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405104] CPU 2: hi: 0, btch: 1 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405106] CPU 3: hi: 0, btch: 1 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405108] DMA32 per-cpu: Jul 6 08:17:51 Ishtar kernel: [34036.405110] CPU 0: hi: 186, btch: 31 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405112] CPU 1: hi: 186, btch: 31 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405114] CPU 2: hi: 186, btch: 31 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405117] CPU 3: hi: 186, btch: 31 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405118] Normal per-cpu: Jul 6 08:17:51 Ishtar kernel: [34036.405120] CPU 0: hi: 186, btch: 31 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405123] CPU 1: hi: 186, btch: 31 usd: 0 Jul 6 08:17:51 Ishtar kernel: [34036.405125] CPU 2: hi: 186, btch: 31 usd: 30 Jul 6 08:17:51 Ishtar kernel: [34036.405127] CPU 3: hi: 186, btch: 31 usd: 15 Jul 6 08:17:51 Ishtar kernel: [34036.405133] active_anon:39844 inactive_anon:31812 isolated_anon:0 Jul 6 08:17:51 Ishtar kernel: [34036.405134] active_file:865726 inactive_file:4534161 isolated_file:35 Jul 6 08:17:51 Ishtar kernel: [34036.405135] unevictable:262348 dirty:195473 writeback:0 unstable:0 Jul 6 08:17:51 Ishtar kernel: [34036.405136] free:57638 slab_reclaimable:344326 slab_unreclaimable:32158 Jul 6 08:17:51 Ishtar kernel: [34036.405137] mapped:26657 shmem:6 pagetables:2971 bounce:0 Jul 6 08:17:51 Ishtar kernel: [34036.405144] DMA free:15868kB min:12kB low:12kB high:16kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15772kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Jul 6 08:17:51 Ishtar kernel: [34036.405150] lowmem_reserve[]: 0 2990 24200 24200 Jul 6 08:17:51 Ishtar kernel: [34036.405159] DMA32 free:179088kB min:2456kB low:3068kB high:3684kB active_anon:48kB inactive_anon:2648kB active_file:196548kB inactive_file:1548864kB unevictable:55768kB isolated(anon):0kB isolated(file):0kB present:3062596kB mlocked:55768kB dirty:52076kB writeback:0kB mapped:10560kB shmem:0kB slab_reclaimable:701508kB slab_unreclaimable:27664kB kernel_stack:64kB pagetables:444kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Jul 6 08:17:51 Ishtar kernel: [34036.405166] lowmem_reserve[]: 0 0 21210 21210 Jul 6 08:17:51 Ishtar kernel: [34036.405175] Normal free:35596kB min:17440kB low:21800kB high:26160kB active_anon:159328kB inactive_anon:124600kB active_file:3266356kB inactive_file:16587780kB unevictable:993624kB isolated(anon):0kB isolated(file):140kB present:21719040kB mlocked:993624kB dirty:729816kB writeback:0kB mapped:96068kB shmem:24kB slab_reclaimable:675796kB slab_unreclaimable:100968kB kernel_stack:3320kB pagetables:11440kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Jul 6 08:17:51 Ishtar kernel: [34036.405181] lowmem_reserve[]: 0 0 0 0 Jul 6 08:17:51 Ishtar kernel: [34036.405185] DMA: 1*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15868kB Jul 6 08:17:51 Ishtar kernel: [34036.405194] DMA32: 26498*4kB 8649*8kB 150*16kB 41*32kB 3*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 179088kB Jul 6 08:17:51 Ishtar kernel: [34036.405204] Normal: 7071*4kB 557*8kB 20*16kB 2*32kB 2*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 35428kB Jul 6 08:17:51 Ishtar kernel: [34036.405214] 5410107 total pagecache pages Jul 6 08:17:51 Ishtar kernel: [34036.405216] 10290 pages in swap cache Jul 6 08:17:51 Ishtar kernel: [34036.405218] Swap cache stats: add 455867, delete 445577, find 338111/357759 Jul 6 08:17:51 Ishtar kernel: [34036.405221] Free swap = 8151272kB Jul 6 08:17:51 Ishtar kernel: [34036.405222] Total swap = 8393924kB Jul 6 08:17:52 Ishtar kernel: [34036.530592] 6291455 pages RAM Jul 6 08:17:52 Ishtar kernel: [34036.530595] 104293 pages reserved Jul 6 08:17:52 Ishtar kernel: [34036.530597] 3301623 pages shared Jul 6 08:17:52 Ishtar kernel: [34036.530598] 2859224 pages non-shared _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 2010-07-07 9:30 ` Linda A. Walsh @ 2010-07-07 21:01 ` Linda Walsh 0 siblings, 0 replies; 29+ messages in thread From: Linda Walsh @ 2010-07-07 21:01 UTC (permalink / raw) To: Dave Chinner, xfs-oss > Dave Chinner wrote: >> Can you send me a link to a metadump image of the filesystem so I can >> look at the broken directories in detail? ----- Don't have link - not sure where I'd put it up for download, Would there be a place you'd want an upload, or I it's small enough to email, but maybe not to the list. with the deletions, and compressed with unix util 7z, it's 2.7M. xfs_dump options were 'xfs_metadump -o -w -g /dev/Home/Home metadump.out _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 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: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 1 sibling, 1 reply; 29+ messages in thread From: Linda A. Walsh @ 2010-06-30 0:01 UTC (permalink / raw) To: Dave Chinner, xfs-oss Dave Chinner wrote: --------------------------------------------------------------------------------------------------- >> Ishtar:/Torrents> 'ls' -ni bad* ls: cannot access bad/30-Omoide >> to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory >> ls: cannot access bad/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory >> ls: cannot access bad/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory >> bad: >> total 0 >> 2359101 ?????????? ? ? ? ? ? 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3 >> 2354946 ?????????? ? ? ? ? ? 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3 >> 2354949 ?????????? ? ? ? ? ? 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3 >> ls: cannot access bad2/30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory >> ls: cannot access bad2/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory >> ls: cannot access bad2/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory > > Those file names have a weird character in them - are you sure that > the terminal supports that character set and is not mangling it and > hence not matching what is actually stored on disk? ----- Those files were 'fine' before today. I know it is not a terminal problem -- I told ls to list all files in the directory -- then it says "no such file". Can you say that "*" shouldn't match everything? Those question marks are in the place for the size! There are no weird characters in those file names. Here are the same files in another directory: mp3> ll 3* -rwx------ 1 3255702 2010-06-14 10:54 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3* -rwx------ 1 3272004 2010-06-14 10:54 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3* -rwx------ 1 3234876 2010-06-14 10:54 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3* The fields it can't display are the file size, time and dates! The names display ok! How can file size, time and date be in unprintable characters that "ls" can't display? _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ (was xfs_dump problem...) 2010-06-30 0:01 ` Linda A. Walsh @ 2010-06-30 1:06 ` 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 0 siblings, 1 reply; 29+ messages in thread From: Dave Chinner @ 2010-06-30 1:06 UTC (permalink / raw) To: Linda A. Walsh; +Cc: xfs-oss On Tue, Jun 29, 2010 at 05:01:12PM -0700, Linda A. Walsh wrote: > > > Dave Chinner wrote: > --------------------------------------------------------------------------------------------------- > >>Ishtar:/Torrents> 'ls' -ni bad* ls: cannot access bad/30-Omoide > >>to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory > >>ls: cannot access bad/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory > >>ls: cannot access bad/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory > >>bad: > >>total 0 > >>2359101 ?????????? ? ? ? ? ? 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3 > >>2354946 ?????????? ? ? ? ? ? 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3 > >>2354949 ?????????? ? ? ? ? ? 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3 > >>ls: cannot access bad2/30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory > >>ls: cannot access bad2/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory > >>ls: cannot access bad2/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory > > > >Those file names have a weird character in them - are you sure that > >the terminal supports that character set and is not mangling it and > >hence not matching what is actually stored on disk? > ----- > Those files were 'fine' before today. > > I know it is not a terminal problem -- > I told ls to list all files in the directory -- then it says "no such file". > > Can you say that "*" shouldn't match everything? > > Those question marks are in the place for the size! > > There are no weird characters in those file names. I beg to differ ;) > Here are the same files in another directory: > mp3> ll 3* > -rwx------ 1 3255702 2010-06-14 10:54 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3* > -rwx------ 1 3272004 2010-06-14 10:54 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3* > -rwx------ 1 3234876 2010-06-14 10:54 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3* ^^^ That character is a non-ascii character, which is why I was wondering about terminals and character sets. It does not display correctly in mutt (a bold vertical bar) or Vim (a dotted, double character width square) using LANG=en_AU.UTF-8 here.... > The fields it can't display are the file size, time and dates! Yes, I know. To stat a file to get that infomration first you have to open it and that requires getting the file name exactly right. If you try to open a file encoded with one language setting/character set and then decode and re-encode it with another, the raw filename data will be different to what is on disk. Hence when I see filenames with unprintable characters in the mail, it's always worth checking first... > How can file size, time and date be in unprintable characters that "ls" can't display? They aren't. They are printed as ??? because the stat failed and hence they are unknown. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 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 ` Linda A. Walsh 2010-06-30 21:01 ` Stan Hoeppner 0 siblings, 1 reply; 29+ messages in thread From: Linda A. Walsh @ 2010-06-30 1:52 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs-oss Dave Chinner wrote: > On Tue, Jun 29, 2010 at 05:01:12PM -0700, Linda A. Walsh wrote: >> >> Dave Chinner wrote: >> --------------------------------------------------------------------------------------------------- >>>> Ishtar:/Torrents> 'ls' -ni bad* ls: cannot access bad/30-Omoide >>>> to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory >>>> ls: cannot access bad/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory >>>> ls: cannot access bad/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory >>>> bad: >>>> total 0 >>>> 2359101 ?????????? ? ? ? ? ? 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3 >>>> 2354946 ?????????? ? ? ? ? ? 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3 >>>> 2354949 ?????????? ? ? ? ? ? 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3 >>>> ls: cannot access bad2/30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3: No such file or directory >>>> ls: cannot access bad2/31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3: No such file or directory >>>> ls: cannot access bad2/32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3: No such file or directory >>> Those file names have a weird character in them - are you sure that >>> the terminal supports that character set and is not mangling it and >>> hence not matching what is actually stored on disk? >> ----- >> Those files were 'fine' before today. >> >> I know it is not a terminal problem -- >> I told ls to list all files in the directory -- then it says "no such file". >> >> Can you say that "*" shouldn't match everything? >> >> Those question marks are in the place for the size! >> >> There are no weird characters in those file names. > > I beg to differ ;) ---- They are standard UTF-8 characters! What's weird about them?!? Next you'll be complaining about my hair style... ;). > >> Here are the same files in another directory: >> mp3> ll 3* >> -rwx------ 1 3255702 2010-06-14 10:54 30-Omoide to Yakusoku (TV saizu|Reinaʼs Ver.).mp3* >> -rwx------ 1 3272004 2010-06-14 10:54 31-Omoide to Yakusoku (TV saizu|Tomoeʼs Ver.).mp3* >> -rwx------ 1 3234876 2010-06-14 10:54 32-Omoide to Yakusoku (TV saizu|Nanualʼs Ver.).mp3* > ^^^ > That character is a non-ascii character, which is why I was > wondering about terminals and character sets. It does not display > correctly in mutt (a bold vertical bar) or Vim (a dotted, double > character width square) using LANG=en_AU.UTF-8 here.... ---- you don't have the right font for your Vim. :-) I use vim here and it displays in the TTY version, the X version and even the windows version! Anyway -- as you can see above, the files display fine in another directory with the same character. IT's not the vertical bar char. I use UTF-8 characters all over the place -- I created that file manually. Go get 'Bablemap'. It's free (well donation requested) from http://www.babelstone.co.uk/Software/BabelMap.html. My systems handle them 'fine'. That's not the problem here. I have 3 directories that all have copies of files 30-32 in them that are corrupt. I have another directory "Shakugan no Shana II OST", that I can't cd into or ls. Just says 'not found'. This all happened today. They were accessible before today. I'm not sure what changed, other than new files were added. > >> How can file size, time and date be in unprintable characters that "ls" can't display? > > They aren't. They are printed as ??? because the stat failed and > hence they are unknown. ---- Ok, why would the stat fail? There's nothing magical about a 2TB limit? (sigh...) Ideas? Linda _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 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 0 siblings, 1 reply; 29+ messages in thread From: Stan Hoeppner @ 2010-06-30 21:01 UTC (permalink / raw) To: xfs Linda A. Walsh put forth on 6/29/2010 8:52 PM: > I have another directory "Shakugan no Shana II OST", that I can't cd > into or ls. > Just says 'not found'. > > This all happened today. They were accessible before today. I'm not > sure what changed, > other than new files were added. It is interesting that all of these "corrupt" files originate from Japan. The filenames have likely passed through many different character encodings on their journey from their source to your XFS filesystems. And they probably originated on a MS Windows machine. How can you be so certain that there isn't a wonky bit somewhere that's wreaking havoc with BabelMap? Maybe that program has a bug, that after after Y access cycles flips a bit, changes a character, or something along these lines? Did you update this program recently, or any other programs that might affect character encoding/displaying, or anything remotely related to such? Have you done any software updates recently, period? Given the entirety of what we're looking at, and that you're apparently not seeing this with files created in a native English language encoding, I'd say Dave is probably on the right track here. -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* utf-8' chars from Winxp machine may be problem related (was Re: xfs file system in process of becoming corrupt; though xfs_repair...) 2010-06-30 21:01 ` Stan Hoeppner @ 2010-07-07 21:40 ` Linda A. Walsh 2010-07-07 23:40 ` Stan Hoeppner 0 siblings, 1 reply; 29+ messages in thread From: Linda A. Walsh @ 2010-07-07 21:40 UTC (permalink / raw) To: Stan Hoeppner, xfs-oss Stan Hoeppner wrote: > > It is interesting that all of these "corrupt" files originate from Japan. The > filenames have likely passed through many different character encodings on > their journey from their source to your XFS filesystems. And they probably > originated on a MS Windows machine. ---- Actually, while the Japanese comment is true for most, its not true for all -- some have the 'copyright' or 'trademark' symbol in the. > How can you be so certain that there isn't a wonky bit somewhere that's > wreaking havoc with BabelMap? ---- Sorry, I didn't mean to come across with certainty that everything was 'unwonky'. Just that normally these files work correctly -- I have good compatibility across all my tools: 1) logged into linux with a tty (secureCRT that supports unicode), and use "ls" to view them in bash (or use "echo *" in bash) 2) use the tty version of Vim in that tty window 3) the 'X' version of Vim (displayed through cygwin's X server, which also handles unicode), 4) over the net using Samba on the linux server, in windows7 5) editing the files on Win7 using 'Gvim' The "broken" files don't work anywhere. And it is not name or character specific. I had 3-4 occurances of 2-3 names broken in 4 copies of 1 directory, but I also had 2 other copies of that directory that were 'fine' -- same names, same characters -- some corrupt, some not. > Y access cycles flips a bit, changes a character, or something along these > lines? Did you update this program recently, or any other programs that might > affect character encoding/displaying, or anything remotely related to such? > Have you done any software updates recently, period? ---- Have been forced to do file system copies (which I did with an "xfsdump|mbuffer|xfsrestore" pipe running in background. It was there I really began to notice a pattern of problems, though some nightly backups were giving errors as far as a few weeks ago -- with my first NOTICING it (I'm often not attentive to automatic processes that have been working fine for months or years), a few weeks ago, or shortly after upgrading to 2.6.34. Due to an upgrade to SuSE 11.2 about ... 6-8 months back, my normal logs were lost as it changed, **AGAIN**, the system logger (first from syslog->ng-syslog, which was a good thing, but now from ng-syslog to rsyslog -- a step backwards in flexibility), with the result that all my logfile patterns were no longer used and much logging was simply thrown away. AFter I caught it -- switched back to ng-syslog and that's when I began noticing multiple oddities in my log files. > > Given the entirety of what we're looking at, and that you're apparently not > seeing this with files created in a native English language encoding, I'd say > Dave is probably on the right track here. --- Yeah...something to do with character encoding...I'd agree there. But not just foreign -- just "utf-8" some english names but with special symbols: Favorites/Cannabis, EO's & Plant info sources/Plant, Tree sources/The Online Nursery » buckeye tree.URL Favorites/Cannabis, EO's & Plant info sources/Plant, Tree sources/The Online Nursery » Black Walnut.URL Favorites/Hw/Intel® Xeon® Processor Numbers.URL Favorites/Hw/Intel® 5000X Chipset Overview.URL Favorites/Hw/Computer(s), peripherals, parts/Intel CPU and chips.../Intel® Xeon® Processor 5000 Sequence - Technical Documents.URL Favorites/Hw/Computer(s), peripherals, parts/Intel CPU and chips.../Intel® Xeon® Processor Numbers.URL Favorites/Hw/Computer(s), peripherals, parts/Intel CPU and chips.../Intel® Core™ Microarchitecture.URL Favorites/Hw/Computer(s), peripherals, parts/Intel CPU and chips.../How to Choose between Hardware and Software Prefetch on 32-Bit Intel® Architecture - Intel® Software Network.URL Favorites/Hw/Computer(s), peripherals, parts/Intel CPU and chips.../Preparing Applications for Intel® Core™ Microarchitecture.URL Favorites/Microsoft/JSI, INC. - Your Windows Server 2003 - Windows NT - Windows 2000 - Windows XP ® Resource.URL Favorites/Web Technologies/Ajaxian » Behold the, um, Beholder!.URL Favorites/Web Technologies/mezzoblue § css Zen Garden Resources.URL hw/misc+interest/Freedom to Tinker » Blog Archive » Making and Breaking HDCP Handshakes_files hw/misc+interest/Freedom to Tinker » Blog Archive » Making and Breaking HDCP Handshakes.htm Receipts_n_inf_etc/WinZip® Order Confirmation-v14-2009.pdf ----- So (R) and the angular right quote ">>", the paragraph mark... All of the above are filenames that can't be accessed, among several french, spanish, greek and japanese filenames. The french/spanish are from Adobe documentation. Even the proper Knuth spelling of "Latex" with the lowered 't' (theta I believe)...etc. So yup...foreign char delight. I can easily image most or all of these having been imported from my winXP machine at one point -- as I only recently started using Win7. -- and many of the troublsome japanese filenames were 'downloaded japanese anime-related stuff' that I did on my old XP machine -- which I used as a download client while I did work on my Win7 machine... That gave a huge influx of foreign names from a WinXP machine. That could be what made the problem jump out so noticeable -- before it was only maybe 20-30 files out of about a million or more. But in the new batch it was hundreds out of several thousand, so they stand out alot more. -------------------- That said -- and I note _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: utf-8' chars from Winxp machine may be problem related (was Re: xfs file system in process of becoming corrupt; though xfs_repair...) 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 0 siblings, 1 reply; 29+ messages in thread From: Stan Hoeppner @ 2010-07-07 23:40 UTC (permalink / raw) To: xfs Linda A. Walsh put forth on 7/7/2010 4:40 PM: > So yup...foreign char delight. > > I can easily image most or all of these having been imported from my > winXP machine at > one point -- as I only recently started using Win7. -- and many of the > troublsome japanese > filenames were 'downloaded japanese anime-related stuff' that I did on > my old > XP machine -- which I used as a download client while I did work on my > Win7 machine... > That gave a huge influx of foreign names from a WinXP machine. That > could be what > made the problem jump out so noticeable -- before it was only maybe > 20-30 files out of about a million or more. But in the new batch it was > hundreds out of several thousand, so > they stand out alot more. I run into a similar problem frequently when saving downloads to my XFS samba shares via a Windows client. I don't recall ever seeing XFS corruption, but I do have problems manipulating these file names through bash. Quite often I end up having to rename the files through Windows Explorer to something bash can handle. That usually fixes the problem--not always, but usually. Just for comparison, I'm running: Debian stable (Lenny 5.0.4) rolled 2.6.32.9 from kernel.org, XFS in kernel not as module xfsprogs: 2.9.8-1lenny1 bash: 3.2-4 samba: 3.2.5-4lenny9 W2K and XP Pro clients As I've never seriously dealt with character encoding issues (i.e. changed anything related in Debian), I don't even know where/how to find my servers default character encoding. Google isn't being very friendly here. I'm using whatever character encoding is the default for US English Debian Lenny. -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: utf-8' chars from Winxp machine may be problem related (was Re: xfs file system in process of becoming corrupt; though xfs_repair...) 2010-07-07 23:40 ` Stan Hoeppner @ 2010-07-08 0:38 ` Linda A. Walsh 0 siblings, 0 replies; 29+ messages in thread From: Linda A. Walsh @ 2010-07-08 0:38 UTC (permalink / raw) To: Stan Hoeppner; +Cc: xfs Stan Hoeppner wrote: > I run into a similar problem frequently when saving downloads to my XFS samba > shares via a Windows client. I don't recall ever seeing XFS corruption, ---- Just a note: Corrupt isn't exactly the right word -- as it doesn't spread to the rest of the file system as a real corrupt likely would ... It seems to be limited to these filenames -- where you can't remove them, or 'address' them, or rename them. -- and their information in the owner and date fields shows up as question marks. It could be that once I retired any of these disks that contain these files the problem will stay on them. > but I > do have problems manipulating these file names through bash. Quite often I > end up having to rename the files through Windows Explorer to something bash > can handle. That usually fixes the problem--not always, but usually. ---- These files are not visible to explorer -- I tried/looked. I'm running suse -- and they default to UTF-8, which is compatible with Win7 speaking UTF16. It's just my older WinXP clients that have problems emitting characters that become incomprehensible. > As I've never seriously dealt with character encoding issues (i.e. changed > anything related in Debian), I don't even know where/how to find my servers > default character encoding. Google isn't being very friendly here. I'm using > whatever character encoding is the default for US English Debian Lenny. I started to some number of years ago due to having music from foreign lands -- and it's only gotten worse from there :-)...now half my music and video collection has foreign chars in it. But even in english, you there there are unicode display values for colon, slash and backslash, so you can use those usually forbidden characters in filenames -- since they are different characters. They do look slightly different since it's not confusing, but it's better than putting in some substitute. Lots of places a colon is called for in music and movie titles where you can use the full width colon -- don't even need spaces around it:see? (this is where I use Babelmap alot!...when I want to insert my own...). You can find the reverse of character in Firefox with the character identify extension. Something I didn't know -- if you have the Japanese characters, you can use the extension -- and what they call 'Romaji' -- the anglicized version of Japanese -- is just the names of the characters -- which you can read out in the character identifier. Interesting but slow translating. AT least you can sound out the words that way...:-). Read the book "Fonts and encodings", and you'll get hooked, I guarantee it! (google it, it's the first result). > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) 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-30 18:25 ` Michael Monnerie 2010-06-30 23:30 ` rsync and corrupt inodes (was xfs_dump problem) Dave Chinner 1 sibling, 1 reply; 29+ messages in thread From: Michael Monnerie @ 2010-06-30 18:25 UTC (permalink / raw) To: xfs [-- Attachment #1.1.1: Type: Text/Plain, Size: 8441 bytes --] On Mittwoch, 30. Juni 2010 Linda Walsh wrote: > But have another XFS problem that is much more reliably persistent. > I don't know if they are at all related, but since I have this > problem that's a bit "stuck", it's easier to "reproduce". I think my problem is similar. I have a Linux ("orion") running Samba. A Win7 client uses it to store it's "Windows Backup". That's OK. 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. As I cannot delete the broken files, I moved the whole dir away, and did an rsync again. The same file destroyed again on saturn. Some days later, again 2 versions which are destroyed. The difference to Linda is, I get: drwx------+ 2 zmi users 4096 Jun 12 03:15 ./ drwxr-xr-x 7 root root 154 Jun 30 04:00 ../ -rwx------+ 1 zmi users 56640000 Jun 12 03:05 852c268f-cf1a-11de-b09b-806e6f6e6963.vhd* ??????????? ? ? ? ? ? 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd 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/xfs/xfs_inode.c. Caller 0xffffffffa032c0ad [125903.343763] [125903.343791] Pid: 17696, comm: ls Not tainted 2.6.31.12-0.2-desktop #1 [125903.343803] Call Trace: [125903.343821] [<ffffffff81011a19>] try_stack_unwind+0x189/0x1b0 [125903.343840] [<ffffffff8101025d>] dump_trace+0xad/0x3a0 [125903.343858] [<ffffffff81011524>] show_trace_log_lvl+0x64/0x90 [125903.343876] [<ffffffff81011573>] show_trace+0x23/0x40 [125903.343894] [<ffffffff81552b46>] dump_stack+0x81/0x9e [125903.343947] [<ffffffffa0321b4a>] xfs_error_report+0x5a/0x70 [xfs] [125903.344085] [<ffffffffa0321bcc>] xfs_corruption_error+0x6c/0x90 [xfs] [125903.344248] [<ffffffffa032bb84>] xfs_iformat_extents+0x234/0x280 [xfs] [125903.344409] [<ffffffffa032c0ad>] xfs_iformat+0x28d/0x5a0 [xfs] [125903.344569] [<ffffffffa032c542>] xfs_iread+0x182/0x1c0 [xfs] [125903.344729] [<ffffffffa0327938>] xfs_iget_cache_miss+0x78/0x250 [xfs] [125903.344882] [<ffffffffa0327c3c>] xfs_iget+0x12c/0x1b0 [xfs] [125903.345036] [<ffffffffa0347b8e>] xfs_lookup+0xce/0x100 [xfs] [125903.345256] [<ffffffffa0354e6c>] xfs_vn_lookup+0x6c/0xc0 [xfs] [125903.345453] [<ffffffff81157782>] real_lookup+0x102/0x180 [125903.345473] [<ffffffff811598c0>] do_lookup+0xd0/0x100 [125903.345491] [<ffffffff81159e12>] __link_path_walk+0x522/0x880 [125903.345510] [<ffffffff8115a6f6>] path_walk+0x66/0xd0 [125903.345528] [<ffffffff8115a7cb>] do_path_lookup+0x6b/0xb0 [125903.345546] [<ffffffff8115a9d1>] user_path_at+0x61/0xc0 [125903.345565] [<ffffffff811514d1>] vfs_fstatat+0x41/0x90 [125903.345584] [<ffffffff811515ac>] vfs_lstat+0x2c/0x50 [125903.345602] [<ffffffff811515fe>] sys_newlstat+0x2e/0x70 [125903.345621] [<ffffffff8100c682>] system_call_fastpath+0x16/0x1b [125903.345645] [<00007f72dc451e65>] 0x7f72dc451e65 Trying to "xfs_repair -n" seems to find errors, see attachment "repair1.log" Trying to "xfs_repair" crashes, see attachment "repair2.log" Saturns kernel is 2.6.31.12-0.2-desktop from openSUSE 11.2, xfs_repair is 3.1.2 (I tried down several versions down to 3.0.1, all without success). Even after xfs_metadump and xfs_mdrestore the error exists, and cannot be repaired with xfs_repair, because that crashes. I've put a new metadump containing only the broken stuff for public review: http://zmi.at/saturn_bigdata.metadump.only_broken.bz2 (197 MB) What should I do, apart of ripping the whole filesystem and copying new? The problem is, would be destroyed again, just like it did 4 times now. -- 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.1.2: repair1.log --] [-- Type: text/x-log, Size: 1919 bytes --] Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 would have corrected attribute entry count in inode 649642 from 40 to 0 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, would clear attr fork would have cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, would clear attr fork would have cleared inode 2195133988 would have corrected attribute entry count in inode 2902971474 from 163 to 0 would have corrected attribute totsize in inode 2902971474 from 6 to 4 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, would clear attr fork would have cleared inode 2195133988 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, would clear attr fork would have cleared inode 649790 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. [-- Attachment #1.1.3: repair2.log --] [-- Type: text/x-log, Size: 1597 bytes --] Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 data fork in inode 2195133988 claims metadata block 537122652 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. [-- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* rsync and corrupt inodes (was xfs_dump problem) 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 ` Dave Chinner 2010-07-01 8:25 ` Michael Monnerie 2010-07-07 21:56 ` Linda Walsh 0 siblings, 2 replies; 29+ messages in thread From: Dave Chinner @ 2010-06-30 23:30 UTC (permalink / raw) To: Michael Monnerie; +Cc: xfs On Wed, Jun 30, 2010 at 08:25:20PM +0200, Michael Monnerie wrote: > On Mittwoch, 30. Juni 2010 Linda Walsh wrote: > > But have another XFS problem that is much more reliably persistent. > > I don't know if they are at all related, but since I have this > > problem that's a bit "stuck", it's easier to "reproduce". > > I think my problem is similar. I have a Linux ("orion") running Samba. > A Win7 client uses it to store it's "Windows Backup". That's OK. > > 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)? > As I cannot delete the broken files, I moved the whole dir away, > and did an rsync again. The same file destroyed again on saturn. > Some days later, again 2 versions which are destroyed. > > The difference to Linda is, I get: > drwx------+ 2 zmi users 4096 Jun 12 03:15 ./ > drwxr-xr-x 7 root root 154 Jun 30 04:00 ../ > -rwx------+ 1 zmi users 56640000 Jun 12 03:05 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? > 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/xfs/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> > [125903.343791] Pid: 17696, comm: ls Not tainted 2.6.31.12-0.2-desktop #1 That's getting a bit old now. 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. > Trying to "xfs_repair -n" seems to find errors, see attachment "repair1.log" 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.... > Trying to "xfs_repair" crashes, see attachment "repair2.log" > > Saturns kernel is 2.6.31.12-0.2-desktop from openSUSE 11.2, > xfs_repair is 3.1.2 (I tried down several versions down to 3.0.1, all without success). > > Even after xfs_metadump and xfs_mdrestore the error exists, and cannot be > repaired with xfs_repair, because that crashes. > > I've put a new metadump containing only the broken stuff for public review: > http://zmi.at/saturn_bigdata.metadump.only_broken.bz2 (197 MB) I'll take a look. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: rsync and corrupt inodes (was xfs_dump problem) 2010-06-30 23:30 ` rsync and corrupt inodes (was xfs_dump problem) Dave Chinner @ 2010-07-01 8:25 ` Michael Monnerie 2010-07-02 2:42 ` Dave Chinner 2010-07-07 21:56 ` Linda Walsh 1 sibling, 1 reply; 29+ messages in thread From: Michael Monnerie @ 2010-07-01 8:25 UTC (permalink / raw) To: xfs [-- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: rsync and corrupt inodes (was xfs_dump problem) 2010-07-01 8:25 ` Michael Monnerie @ 2010-07-02 2:42 ` Dave Chinner 2010-07-02 6:21 ` Michael Monnerie 0 siblings, 1 reply; 29+ messages in thread From: Dave Chinner @ 2010-07-02 2:42 UTC (permalink / raw) To: Michael Monnerie; +Cc: xfs On Thu, Jul 01, 2010 at 10:25:03AM +0200, Michael Monnerie wrote: > 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. So it's the rsync daemon on saturn that is doing all the IO? > 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. "getfattr -d" > > > 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 ..... > 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" >From the metadump, I can see that other valid .vhd files are in local format with: core.forkoff = 9 a.sfattr.hdr.totsize = 83 a.sfattr.hdr.count = 1 a.sfattr.list[0].namelen = 12 a.sfattr.list[0].valuelen = 64 a.sfattr.list[0].root = 1 a.sfattr.list[0].secure = 0 a.sfattr.list[0].name = "SGI_ACL_FILE" a.sfattr.list[0].value = <snipped> All the broken inodes are in the same format as the valid .vhd files, but the shortform attribute header is completely toast. Once I correct the header and the lengths, the only thing that looks wrong is: xfs_db> p a.sfattr.list[0].name a.sfattr.list[0].name = "\035GI_ACL_FILE" The first character of the name is bad, everything after that - including the attribute value - is identical to that on other inodes. What this implies is that we've overwritten the start of the attribute fork with something, and that looks exactly like the swap extents problems that we've fixed recently.... > > 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 ;-) Ok, so we have identified a potential cause. Either disabling fsr or upgrading to 2.6.34 should be sufficient to avoid the problem. If no problem show up now you are on 2.6.34, then I'd switch fsr back on and see if they show up again... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: rsync and corrupt inodes (was xfs_dump problem) 2010-07-02 2:42 ` Dave Chinner @ 2010-07-02 6:21 ` Michael Monnerie 2010-07-04 22:53 ` Dave Chinner 0 siblings, 1 reply; 29+ messages in thread From: Michael Monnerie @ 2010-07-02 6:21 UTC (permalink / raw) To: xfs [-- Attachment #1.1: Type: Text/Plain, Size: 2091 bytes --] On Freitag, 2. Juli 2010 Dave Chinner wrote: > So it's the rsync daemon on saturn that is doing all the IO? Yes. > > 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. > > "getfattr -d" Sorry, doesn't work: # getfattr -d 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd getfattr: 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd: Structure needs cleaning > The first character of the name is bad, everything after that - > including the attribute value - is identical to that on other > inodes. What this implies is that we've overwritten the start of > the attribute fork with something, and that looks exactly like the > swap extents problems that we've fixed recently.... > > > > Yes, xfs_fsdr was running. Disabled it now, and compiled and > > changed to kernel 2.6.34 now. Hope that's OK ;-) > > Ok, so we have identified a potential cause. Either disabling fsr or > upgrading to 2.6.34 should be sufficient to avoid the problem. If no > problem show up now you are on 2.6.34, then I'd switch fsr back on > and see if they show up again... So far, so good. I'm on 2.6.34 now. Is there any chance for a fixed version of xfs_repair, so that I can either get rid of the 4 broken files (i.e. delete them), or repair the filesystem? ATM, xfs_repair asserts on this filesystem. -- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: rsync and corrupt inodes (was xfs_dump problem) 2010-07-02 6:21 ` Michael Monnerie @ 2010-07-04 22:53 ` Dave Chinner 2010-07-12 11:28 ` Michael Monnerie 0 siblings, 1 reply; 29+ messages in thread From: Dave Chinner @ 2010-07-04 22:53 UTC (permalink / raw) To: Michael Monnerie; +Cc: xfs On Fri, Jul 02, 2010 at 08:21:51AM +0200, Michael Monnerie wrote: > On Freitag, 2. Juli 2010 Dave Chinner wrote: > > So it's the rsync daemon on saturn that is doing all the IO? > > Yes. > > > > 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. > > > > "getfattr -d" > > Sorry, doesn't work: > > # getfattr -d 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd > getfattr: 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd: Structure needs > cleaning I meant run it on an uncorrupted version of the file, but I don't think that information is needed now... > > The first character of the name is bad, everything after that - > > including the attribute value - is identical to that on other > > inodes. What this implies is that we've overwritten the start of > > the attribute fork with something, and that looks exactly like the > > swap extents problems that we've fixed recently.... > > > > > > Yes, xfs_fsdr was running. Disabled it now, and compiled and > > > changed to kernel 2.6.34 now. Hope that's OK ;-) > > > > Ok, so we have identified a potential cause. Either disabling fsr or > > upgrading to 2.6.34 should be sufficient to avoid the problem. If no > > problem show up now you are on 2.6.34, then I'd switch fsr back on > > and see if they show up again... > > So far, so good. I'm on 2.6.34 now. Is there any chance for a fixed > version of xfs_repair, so that I can either get rid of the 4 broken > files (i.e. delete them), or repair the filesystem? ATM, xfs_repair > asserts on this filesystem. What version of xfs_repair? v3.1.2 does not assert fail here on the metadump image you posted, but it does take 3 runs to fix up all the problems with the busted inodes.... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: rsync and corrupt inodes (was xfs_dump problem) 2010-07-04 22:53 ` Dave Chinner @ 2010-07-12 11:28 ` Michael Monnerie 0 siblings, 0 replies; 29+ messages in thread From: Michael Monnerie @ 2010-07-12 11:28 UTC (permalink / raw) To: xfs [-- Attachment #1.1.1: Type: Text/Plain, Size: 1452 bytes --] Been on holidays, so I didn't answer till now... On Montag, 5. Juli 2010 Dave Chinner wrote: > > So far, so good. I'm on 2.6.34 now. Is there any chance for a fixed > > version of xfs_repair, so that I can either get rid of the 4 broken > > files (i.e. delete them), or repair the filesystem? ATM, xfs_repair > > asserts on this filesystem. > > What version of xfs_repair? v3.1.2 does not assert fail here on the > metadump image you posted, but it does take 3 runs to fix up all the > problems with the busted inodes.... Do you mean this one? http://zmi.at/saturn_bigdata.metadump.only_broken.bz2 (197 MB) I have xfs_repair 3.1.2, and made a shell script which 10x does xfs_repair that image, I attached the output here. Doesn't seem to repair anything, just crashing. Maybe I did something wrong? I configured xfsprogs 3.1.2 with CFLAGS=-march=athlon64-sse3 ./configure --prefix=/usr and then make;make install I recompiled the whole thing now with # gcc --version gcc (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839] and it's the same output as ever. Either you meant another metadump, or there is a problem somewhere I don't see. -- 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.1.2: repair.log --] [-- Type: text/x-log, Size: 15828 bytes --] xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 data fork in inode 2195133988 claims metadata block 537122652 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 data fork in inode 2195133988 claims metadata block 537122652 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 data fork in inode 2195133988 claims metadata block 537122652 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 data fork in inode 2195133988 claims metadata block 537122652 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 data fork in inode 649642 claims metadata block 537266460 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 data fork in inode 2195133988 claims metadata block 537122652 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 data fork in inode 649642 claims metadata block 537266460 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 data fork in inode 649642 claims metadata block 537266460 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 data fork in inode 2195133988 claims metadata block 537122652 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. xfs_repair version 3.1.2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrected attribute entry count in inode 649642, was 40, now 0 problem with attribute contents in inode 649642 local inode 649790 attr too small (size = 1, min size = 4) bad attribute fork in inode 649790, clearing attr fork clearing inode 649790 attributes cleared inode 649790 - agno = 1 local inode 2195133988 attr too small (size = 3, min size = 4) bad attribute fork in inode 2195133988, clearing attr fork clearing inode 2195133988 attributes cleared inode 2195133988 corrected attribute entry count in inode 2902971474, was 163, now 0 corrected attribute entry totsize in inode 2902971474, was 6, now 4 problem with attribute contents in inode 2902971474 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 3 - agno = 2 - agno = 4 - agno = 5 data fork in inode 2195133988 claims metadata block 537122652 - agno = 6 - agno = 7 xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed. [-- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: rsync and corrupt inodes (was xfs_dump problem) 2010-06-30 23:30 ` rsync and corrupt inodes (was xfs_dump problem) Dave Chinner 2010-07-01 8:25 ` Michael Monnerie @ 2010-07-07 21:56 ` Linda Walsh 1 sibling, 0 replies; 29+ messages in thread From: Linda Walsh @ 2010-07-07 21:56 UTC (permalink / raw) To: Dave Chinner; +Cc: Michael Monnerie, xfs Dave Chinner wrote: > On Wed, Jun 30, 2010 at 08:25:20PM +0200, Michael Monnerie wrote: >> From another Linux ("saturn"), I do an rsync via an rsync-module, ... > Are you running rsync locally on saturn ---- Data point: I have two file systems with corruption -- one recent one had a WinXP client (as well as a Win7, and linux host), dumping foreign names into the file system (the Win clients through samba). However, my "home partition" use to regularly be used to backup the WinXP's home dir via **rsync**. Some of those files were _un_readable on WinXP (like ones containing copyright symbols / registered trademark symbols, etc) -- but at the time, they WERE readable on linux. Now some of those same files are no longer readable on linux. Just thought I'd mention that on my 'home' partition, the corruption is in files that were transfered with rsync. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2010-07-12 11:25 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.