Hi Marcus Alanen DC wrote:
> Hi! We are experiencing a small problem using reiserfs. > Currently there is one file which can't be accessed. > > [root]# ls -1 4113. > ls: 4113.: Permission denied > [root]# ls -1 | grep 4113\. > 4113. > [root]# > > Also any stat, cat etc. doesn't work, but the file is there, and is also > supposed to be there. There are only a bit over 5000 files in the > directory. > > I read some older posts to the mailing list, and as far as I've > understood it, there are two or more files sharing the same object-id, > and this isn't supposed to happen. I can't access this file, because > the first file is already in the cache and a mix-up occurs. > > The system is a big mailserver, a dual-Pentium 3 with software RAID-0 > with Ultra-160 SCSI disks (36 GB IBM 36lzx Ultra Star), totalling a 161 GB > /dev/md0, of which only 42% in use (it has been around 60-70%, but not > any bigger, ever). > > The kernel in use has been 2.4.5 (with umount fix, Axboe's block-highmem, > and Hedrick's ide patch), but due to virtual memory problems we > upgraded to 2.4.12 (with Andrea Arcangeli's aa1 patch and Axboe's > block-highmem). Both Linus Torvalds' tree, not -ac series. > While 2.4.5 had VM problems, there never were any problems with reiserfs. > 2.4.5 has been in use about 4 months. > Now, 9 days after upgrading to 2.4.12, two files had this "Permission > denied" problem. One file mysteriously works now, maybe thanks to some > fiddling with directories & files. (?? A one-in-a-million chance that we > purged the right cache entry by mistake??) The other one is still > inaccessible. > > Both 2.4.5 and 2.4.12 have spontaneously booted, several times. This most > likely has aboslutely nothing to do with reiser, and we haven't seen > reiserfs complain when booting up again. > > The output of plain "/sbin/debugreiserfs /dev/md0" > > <-------------debugreiserfs, 2001-------------> > reiserfsprogs 3.x.0j > Super block of format 3.6 found on the 0x3 in block 16 > Block count 42182320 > Blocksize 4096 > Free blocks 24726683 > Busy blocks (skipped 16, bitmaps - 1288, journal blocks - 8193 > 1 super blocks, 17446139 data blocks > Root block 83962 > Journal block (first) 18 > Journal dev 0 > Journal orig size 8192 > Filesystem state ERROR > Tree height 5 > Hash function used to sort names: "r5" > Objectid map size 156, max 972 > Version 2 > > (Filesystem state ERROR because it is mounted read-write, I assume) > > I put the object-id map on http://www.abo.fi/~msa/object-ids, in case > somebody wants to have a look. I really don't know what to look for, > though :( > > Is this still an unknown issue? Any good solutions? Are there reiserfs > differences between 2.4.12 and e.g. 2.4.14? > > A possible temporary fix: because there is another file in the cache > with the same object-id, one hopefully easy way out would be to boot > the box, and immediately move the file we have problems with, to another > filesystem. Then move it back, thus acquiring a fresh object id. > Sounds good? > Yes, but you first have to make sure that "shared objectids" is your problem. I think you should run reiserfsck first. Thanks, vs > > Sorry for the long mail. Since this seems to be an unresolved issue I > tried to give as much relevant information as possible. I am subscribed to > the reiserfs mailing list, no CC necessary. > > Regards, > Marcus
