April 3, 200719 yr I've been struggling to copy things to the server. See my unable to access folder post. So, I would copy some, have to reboot, wait for a parity check and repeat. Now, I can't even do that. As soon as I try to copy a file over, I get a Can't copy file: Invalid file handle error. This has happened several times with different files. I've attached the syslog from the last time this happened. Thanks
April 3, 200719 yr It looks like there is file system corruption on disk1. You have two options: 1. If you want to preserve the data on the disk you can attempt to repair the file system. 2. If you do not care about the data on the disk, you can make it appear 'Unformatted' and then you'll be able to Format it next time you restart the server. Instructions for Option 1 - Attempt to repair file system. After the system boots, go to the Main page and Cancel any parity-sync that's running and then Stop the array. Next, from a telnet window or console, type this command: reiserfsck /dev/hda1 When prompted, type "Yes" to continue. This will probably report that you need to run 'reiserfsck' again with the '--rebuild-tree' option. If so, then type: reiserfsck --rebuild-tree /dev/hda1 Let this finish, and then type: reiserfsck /dev/hda1 to verify the file system is ok. Now reboot server and see if this solved the problem. Instructions for Option 2 - Force drive to appear 'unformatted' After the system boots, go to the Main page and Cancel any parity-sync that's running and then Stop the array. Next, from a telnet window or console, type this command: dd if=/dev/zero of=/dev/hda bs=4096 count=4096 Now reboot server and your disk1 should appear 'unformatted'.
April 3, 200719 yr When this happened to me, I chose Option #1. BUT.... I needed to do it more than once. (just read the last few lines that reiserfsck reports; if it reports file system corruptions, then I would follow the reiserfsck directions to either "rebuild-tree" or "fix-fixable". Completion of reiserfsck created a "lost+found" directory for files which the filesystem didn't know where to put them.
April 4, 200719 yr Tom, How were you able to determine that the problem existed on disk1 by looking at the syslog provided? I had the exact same problem occur so I reverted to 3.0 final. I have 7 disks in the array but couldn't figure out which disk might have had the file system problems. Is there a command to list all of the drives installed, both SATA and PATA? Thanks! It looks like there is file system corruption on disk1. You have two options: 1. If you want to preserve the data on the disk you can attempt to repair the file system. 2. If you do not care about the data on the disk, you can make it appear 'Unformatted' and then you'll be able to Format it next time you restart the server.
April 4, 200719 yr There was a "kernel exception" in the log, starting with these lines: Apr 3 06:19:29 Tower kernel: [44036.340800] ------------[ cut here ]------------ Apr 3 06:19:29 Tower kernel: [44036.340845] kernel BUG at fs/reiserfs/bitmap.c:1287! Apr 3 06:19:29 Tower kernel: [44036.340884] invalid opcode: 0000 [#1] A couple of people have reported this same problem with similar syslog entries (all reporting bug at fs/reiserfs/bitmap.c). This particular bug is reporting an "impossible" state in a reiserfs data structure. I'm still trying to research this, but I think the reiserfs code in 2.6.x kernel does more/different checking than in 2.4.x kernel & that running under unRAID 3.x this inconsistency exists but is undetected. Running reiserfsck with --rebuild-tree (as explained in previous post) seems to correct the problem. As for which disk this applies to... unfortunately there's nothing in the syslog report which says this. You can manually check each disk's filesystem by doing this: 1. Stop array. 2. Go to Devices page and look at your set of disks. There will be an identifier in paranthesis, e.g., disk2 device: pci-0000:00:1f.2-scsi-0:0:0:0 (sdb) scsi-SATA_ST380817AS_5MR30RW2 here the identifier is "sdb". Now from telnet window or console type: reiserfsck /dev/sdb1 Note that you need to append a "1" to the identifier in the above command. The reiserfsck program will prompt you to type "Yes" to continue. It might take a few minutes to complete, and at the end it will generate a report about the health of your file system. You can do this for each disk. If you find that you need to repair a disk, upon array re-start you will need to re-generate parity (just run a parity-check - it may report sync-errors, but will correct them). We will add a feature to do all this via Management Utility probably in 4.1, but maybe in another 4.0-beta if more people are running into this problem.
April 5, 200719 yr Author Thanks, Tom, that worked! I just copied over about 29GB in 6000 files without a problem. I copied them over in batches of about 2GB each. Now, I'll try to copy over large files (1.5-2GB each) and see if that other problem I had pops back up.
April 6, 200719 yr Wow - I issued the reiserfsck --rebuild-tree and it started well... processed at about 20MB/s.. now its done about 30% of the drive but the speed has dropped to 2MB/s !! Its a 500GB SATA drive that is fairly full.. i'll be pretty depressed if I've lost the data on this drive. I do have another linux system in the house - an older Redhat Fedora Core4. Is it a possibility to mount the drive there, and try to copy the data off if this rebuild-tree doesn't work? FYI - the only thing appearing in the syslog while the fsck is processing is: Apr 6 12:37:04 Tower kernel: [51947.120000] md0: import [8,16] (sdb) WDC WD5000AAKS-0 WD-WMAPW1381419 offset: 63 size: 488386552 Apr 6 12:37:04 Tower kernel: [51947.340000] md1: import [8,0] (sda) WDC WD5000AAKS-0 WD-WMAPW1403310 offset: 63 size: 488386552 Apr 6 12:37:04 Tower kernel: [51947.340000] md2: import [33,0] (hde) ST3200822A 3LJ16K3Q offset: 63 size: 195360952 Apr 6 12:37:04 Tower kernel: [51947.530000] md3: import [33,64] (hdf) ST3300831A 3NF0CF1Y offset: 63 size: 293036152 Apr 6 12:37:04 Tower kernel: [51947.540000] md4: import [34,0] (hdg) ST3300622A 3NF1EGN2 offset: 63 size: 293036152 Apr 6 12:37:04 Tower kernel: [51947.540000] md5: import [34,64] (hdh) ST3250823A 5ND11JYD offset: 63 size: 244198552 Apr 6 12:37:04 Tower kernel: [51947.540000] md6: import [3,0] (hda) ST3500841A 3PM06GCF offset: 63 size: 488386552 Apr 6 12:37:04 Tower kernel: [51947.540000] md7: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md8: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md9: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md10: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md11: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md12: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md13: import: no device
April 6, 200719 yr Wow - I issued the reiserfsck --rebuild-tree and it started well... processed at about 20MB/s.. now its done about 30% of the drive but the speed has dropped to 2MB/s !! Its a 500GB SATA drive that is fairly full.. i'll be pretty depressed if I've lost the data on this drive. I do have another linux system in the house - an older Redhat Fedora Core4. Is it a possibility to mount the drive there, and try to copy the data off if this rebuild-tree doesn't work? yes, you could mount it on the other box, BUT... it would see the same corruption of your file system. I'd let the reiserfsck finish, even if it is going slowly. FYI - the only thing appearing in the syslog while the fsck is processing is: Apr 6 12:37:04 Tower kernel: [51947.120000] md0: import [8,16] (sdb) WDC WD5000AAKS-0 WD-WMAPW1381419 offset: 63 size: 488386552 Apr 6 12:37:04 Tower kernel: [51947.340000] md1: import [8,0] (sda) WDC WD5000AAKS-0 WD-WMAPW1403310 offset: 63 size: 488386552 Apr 6 12:37:04 Tower kernel: [51947.340000] md2: import [33,0] (hde) ST3200822A 3LJ16K3Q offset: 63 size: 195360952 Apr 6 12:37:04 Tower kernel: [51947.530000] md3: import [33,64] (hdf) ST3300831A 3NF0CF1Y offset: 63 size: 293036152 Apr 6 12:37:04 Tower kernel: [51947.540000] md4: import [34,0] (hdg) ST3300622A 3NF1EGN2 offset: 63 size: 293036152 Apr 6 12:37:04 Tower kernel: [51947.540000] md5: import [34,64] (hdh) ST3250823A 5ND11JYD offset: 63 size: 244198552 Apr 6 12:37:04 Tower kernel: [51947.540000] md6: import [3,0] (hda) ST3500841A 3PM06GCF offset: 63 size: 488386552 Apr 6 12:37:04 Tower kernel: [51947.540000] md7: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md8: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md9: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md10: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md11: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md12: import: no device Apr 6 12:37:04 Tower kernel: [51947.540000] md13: import: no device Assuming you stopped your array before starting the reiserfsck command, these are harmless status messages.
April 6, 200719 yr Thanks Joe - yup, the array was stopped prior to doing this. Time to just crack a few beers and let it run this weekend I guess!
April 9, 200719 yr Just to close the loop on this problem - the reiserfsck --build-tree completed successfully (it took almost 36 hours and had dropped to a speed of about 600kb/s at the end of it all.) It does not appear as though I have any data loss, which is great. I forced a parity check after it completed and it ran fine and found about 1000 sync errors. All appears well now, but to be safe i ran the fsck on the other drives too to correct all problems. Thanks for the help!
April 9, 200719 yr Probably it did drop into PIO mode due to error at some point. Keep an eye on that drive.
Archived
This topic is now archived and is closed to further replies.