Hi Micah,
Do you have the full e2fsck transcript (it looks like what you
submitted to BTS was only a partial transcript)?
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
The other thing might be worth trying is re-running e2fsck and see
what you see, via "e2fsck -f /dev/mapper/vg_hoopoe0-backups". The
PROGRAMMING BUG error can also result by having a hard drive returning
different data when a particular inode tabke block is read at
different times. So if there is something flakey in your storage
device --- for example, if you have a RAID 1 setup, and the two
mirrors aren't synchronized, it could be that e2fsck would read from
disk #1 during pass 1, and then later when pass #4, if the disk read
comes from disk #2 returns different data, you will also get the
PROGRAMMING BUG error.
It should also be the case after a single run of e2fsck, if all
answers are answered with 'yes', that a subsequent run of e2fsck
should find no problems. This, of course, is assuming that there are
no e2fsck bugs and that storage device is reliable. (That is, data
written to a block will be read back when the block is read, and data
read from a block at time T and data read time T+n will be the same,
if there are no intervening writes to that block.)
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
