Hi Ted, I was able to do the fsck again (did it twice) and no error was reported.
Excerpts from Theodore Tso's message of Sat Nov 14 16:21:51 -0500 2009: > Also, can you tell me something about the files which got the > PROGRAMMING BUG error? It would be useful to see the pathname and > inode breakdown of the inode(s) in question. For example, for inode > 223806323, the following debugfs commands will give the pathname and > inode: > > % debugfs /dev/mapper/vg_hoopoe0-backups > debugfs: ncheck <223806323> > debugfs: stat <223806323> > debugfs: quit I had some difficulty getting debugfs to work properly, not a utility I have had much experience with (fortunately, thanks to you!). I have discovered that it takes some time to get the debugfs: prompt on this filesystem (much longer than I thought, leading me to believe I had to actually type "debugfs:"), I think that might be related to the fact that it is about a terabyte. Have you seen similar response times for large filesystems, or does this point to some other issue? After I waited for a long time, and got the prompt I then determined, through trial-and-error, that I should not surround the inode with <> as you say above :) Once I resolved that, I was above to almost immediately get a result when I run the ncheck on an inode, but I dont get returned to the debugfs: prompt for a very long time, it sits there like this: debugfs: ncheck 216499134 Inode Pathname 216499134 /lost+found/#216499134 After a while, I hit control-c, at which point I will get the debugfs: prompt again. I figured I was something obvious here, tried ^D, EOF, quit, and other things, I tried also providing those commands in a -f cmd_file, but I got a similar result. Then I tried leaving it for 8 hours and hey! I got the prompt again. I guess what is happening is that its spitting out the inode that is associated with the file, and then it is scouring the disk for other instances of that inode, so it has to look through everything and that takes a while on a terabyte drive? In any case, I provided you with a list of some 100 or so inodes in the fsck output, I would expect to get a full result of all of those in several weeks time, so I'm not sure how useful it is to do every single one of them. Here is what I have so far, after a day and a half: r...@hoopoe:~# debugfs /dev/mapper/vg_hoopoe0-backups debugfs 1.41.3 (12-Oct-2008) debugfs: ncheck 216499134 Inode Pathname 216499134 /lost+found/#216499134 debugfs: stat 216499134 216499134: File not found by ext2_lookup debugfs: ncheck 210373677 Inode Pathname 210373677 /maildir/riseup.net/k/kat/weekly.4/.Davis High School E-mails/cur/1246118958.M900810P11555V0000000000000704I0178046D_0.albatross,S=5054:2,RS 210373677 /maildir/riseup.net/k/kat/monthly.3/.Davis High School E-mails/cur/1246118958.M900810P11555V0000000000000704I0178046D_0.albatross,S=5054:2,RS 210373677 /maildir/riseup.net/k/kat/weekly.3/.Davis High School E-mails/cur/1246118958.M900810P11555V0000000000000704I0178046D_0.albatross,S=5054:2,RS 210373677 /maildir/riseup.net/k/kat/weekly.2/.Davis High School E-mails/cur/1246118958.M900810P11555V0000000000000704I0178046D_0.albatross,S=5054:2,RS 210373677 /maildir/riseup.net/k/kat/rotate.tmp/.Davis High School E-mails/cur/1246118958.M900810P11555V0000000000000704I0178046D_0.albatross,S=5054:2,RS 210373677 /maildir/riseup.net/k/kat/monthly.2/.Davis High School E-mails/cur/1246118958.M900810P11555V0000000000000704I0178046D_0.albatross,S=5054:2,RS 210373677 /maildir/riseup.net/k/kat/daily.1/.Davis High School E-mails/cur/1246118958.M900810P11555V0000000000000704I0178046D_0.albatross,S=5054:2,RS In case your mail program wraps these, there are 7 lines here, and there are spaces in the names, and the 'debugfs:' prompt has not been returned yet. micah
signature.asc
Description: PGP signature
