Jens Benecke writes: > ... thus spake Linus when he booted into 2.1.43 (codename 'greased weasel', > IIRC) and trashed his beloved ext2 file system. > > > I have the same problem. 2.4.7 kernel, stock ReiserFS (3.6 format), on a > Duron--650. > > Some files on my large (210G) LVM volume are not accessible any more. I > *suppose* this has something to do with the power failure a couple days > ago, but I am not sure. Anyway, I haven't touched those files for days, not > even read-only (maybe a FTP user has downloaded them though), so there > _shouldn't_ be any reason for them to be damaged. Other files which were > much more frequently used (also read-write) on the server (although on a > different partition), even shortly before the power outage, are intact - > apparently. For example, my mailboes and news spool. > > I get 'permission denied' on stat()ing the files (ls shows the error for > example). Even as root. I cannot chmod() them or do anything else with > them. See: > > --------------------------------------------------------------------------- > server: 05-02-080 Real Me# ls -la > ls: 05-02-080_Real Me_1.mpg: Keine Berechtigung ( == permission denied) > ls: 05-02-080_Real Me_5.mpg: Keine Berechtigung > ls: 05-02-080_Real Me_3.mpg: Keine Berechtigung > ls: 05-02-080_Real Me_2.mpg: Keine Berechtigung > ls: 05-02-080_Real Me_4.mpg: Keine Berechtigung > insgesamt 2 > drwxrwxr-x 2 jens public 248 15. Aug 14:29 . > drwxrwxr-x 26 jens jens 1296 31. Aug 00:38 .. > server: 05-02-080 Real Me# > --------------------------------------------------------------------------- Reiserfsck wizards will response with more authority tomorrow (Moscow time), but I guess you should take latest reiserfsck from ftp://ftp.namesys.com/pub/reiserfsprogs/pre/ and retry. > > Syslog shows this: Nikita. > > --------------------------------------------------------------------------- > Sep 25 17:59:24 server kernel: vs-13070: reiserfs_read_inode2: i/o failure > occurred trying to find stat data of [142679 142774 0x0 SD] > Sep 25 17:59:24 server kernel: is_tree_node: node level 1 does not match to > the expected one 2 > Sep 25 17:59:24 server kernel: vs-5150: search_by_key: invalid format found > in block 41865. Fsck? > Sep 25 17:59:24 server kernel: vs-13070: reiserfs_read_inode2: i/o failure > occurred trying to find stat data of [142679 142680 0x0 SD] > Sep 25 17:59:24 server kernel: is_tree_node: node level 1 does not match to > the expected one 2 > Sep 25 17:59:24 server kernel: vs-5150: search_by_key: invalid format found > in block 41865. Fsck? > Sep 25 17:59:24 server kernel: vs-13070: reiserfs_read_inode2: i/o failure > occurred trying to find stat data of [142679 142810 0x0 SD] > Sep 25 17:59:24 server kernel: is_tree_node: node level 1 does not match to > the expected one 2 > Sep 25 17:59:24 server kernel: vs-5150: search_by_key: invalid format found > in block 41865. Fsck? > Sep 25 17:59:24 server kernel: vs-13070: reiserfs_read_inode2: i/o failure > occurred trying to find stat data of [142679 142775 0x0 SD] > Sep 25 17:59:24 server kernel: is_tree_node: node level 1 does not match to > the expected one 2 > Sep 25 17:59:24 server kernel: vs-5150: search_by_key: invalid format found > in block 41865. Fsck? > Sep 25 17:59:24 server kernel: vs-13070: reiserfs_read_inode2: i/o failure > occurred trying to find stat data of [142679 142697 0x0 SD] > Sep 25 17:59:24 server kernel: is_tree_node: node level 1 does not match to > --------------------------------------------------------------------------- > > etc. > > > OK. I killed proftpd and NFS, umounted the partition, ignored the phone > calls, started reiserfsck in read-only mode. This is what I got: > > --------------------------------------------------------------------------- > # reiserfsck /dev/data/archiv > .... > Will read-only check consistency of the partition > Will put log info to 'stderr' > Do you want to run this program?[N/Yes] (note need to type Yes):Yes > Analyzing journal..nothing to replay (no transactions older than last > flushed one found) > Fetching on-disk bitmap..done > Checking S+tree../ 1 (of 3)/ 2 (of 130)/ 1 (of 119)block 273951 is not > marked as used in the disk bitmap > block 273953 is not marked as used in the disk bitmap > block 273954 is not marked as used in the disk bitmap > block 273957 is not marked as used in the disk bitmap > block 273959 is not marked as used in the disk bitmap > block 273961 is not marked as used in the disk bitmap > block 273963 is not marked as used in the disk bitmap > block 273966 is not marked as used in the disk bitmap > block 273968 is not marked as used in the disk bitmap > block 273970 is not marked as used in the disk bitmap > block 273971 is not marked as used in the disk bitmap > block 273973 is not marked as used in the disk bitmap > block 273975 is not marked as used in the disk bitmap > block 273977 is not marked as used in the disk bitmap > (etc....) > / 2 (of 3)/ 52 (of 108)/ 57 (of 97)node (39637) with wrong level (1581) > found in the tree (should be 1) > Speicherzugriffsfehler (core dumped) > --------------------------------------------------------------------------- > > > Whoops. I don't like this. Let's see: > > --------------------------------------------------------------------------- > server: ~# gdb reiserfsck core.reiserfsck > GNU gdb 19990928 > ... > This GDB was configured as "i686-pc-linux-gnu"... > (no debugging symbols found)... > Core was generated by `reiserfsck /dev/data/archiv'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. > Reading symbols from /lib/ld-linux.so.2...(no debugging symbols > found)...done. > #0 0x8054060 in sync () > (gdb) bt 10 > #0 0x8054060 in sync () > Cannot access memory at address 0xbffff628. > --------------------------------------------------------------------------- > > OK, I don't know much about debugging segfaults and core dumps, so if > anybody could take over from here I'd be glad. What is happening? Do I need > to --rebuild-tree? I'm not doing anything without at least one of you > �bergurus telling me to ;) > > (well, except for sorting out my backups...) > > > Thanks a lot! > > -- > Jens Benecke �������� http://www.hitchhikers.de/ - Europas Mitfahrzentrale
