April 7, 201016 yr First of all "hello" to the community and "thank you" for the help you've unknowingly already supplied me with from the information on this forum. I built my own unRaid box a month or so ago. Supermicro C2SEA mobo Supermicro 5 in 3 cage 2 GB Kingston memory Seagate 1.5 5900 RPM (parity) Seagate 1.5 5900 RPM (data) WD EARS 1.5 (data) All drives on mobo SATA ports Coolermaster 590 The issue I'm currently experiencing is that attempting to rename a folder on a disk share causes the array to reboot. Most recently I experienced the issue on the EARS drive. I tried to rename the folder, array rebooted and started a parity check. I tried to rename the folder again thinking that the reboot may have resolved the issue and it restarted again. This time I just let the parity check finish, which it seemed to do without errors. I don't seem to have any trouble writing to the drive because I had just copied a bunch of files into the folder that I was trying to rename. Reading isn't an issue, we pull movies off of it all the time. Since the syslog gets wiped out on reboot I'm working on getting that setup to write to a file on flash (based on information found in other threads) so I can see if there's any errors etc... I can tell you there don't seem to be any related SMART errors on any of the drives. There's one High Fly Write on one of the Seagate's but that's been there from the very beginning and I don't see anything else occurring. Like I said, I am working on getting a copy of the syslog from the time of the reboot. I'm not looking for someone to do the leg work for me. But I just wanted to post the symptoms in case anyone has seen something similar, might have some troubleshooting steps that I haven't thought of, or may have an idea what might be going on (file system corruption?). It's difficult to troubleshoot because the array is pretty heavily used by my family. Also once something does occur I prefer to let the parity check complete which means a maximum of one troubleshooting step per night if it triggers a reboot. Thanks again.
April 7, 201016 yr First of all "hello" to the community and "thank you" for the help you've unknowingly already supplied we with from the information on this forum. I built my own unRaid box a month or so ago. Supermicro C2SEA mobo Supermicro 5 in 3 cage 2 GB Kingston memory Seagate 1.5 5900 RPM (parity) Seagate 1.5 5900 RPM (data) WD EARS 1.5 (data) All drives on mobo SATA ports Coolermaster 590 The issue I'm currently experiencing is that attempting to rename a folder on a disk share causes the array to reboot. Most recently I experienced the issue on the EARS drive. I tried to rename the folder, array rebooted and started a parity check. I tried to rename the folder again thinking that the reboot may have resolved the issue and it restarted again. This time I just let the parity check finish, which it seemed to do without errors. I don't seem to have any trouble writing to the drive because I had just copied a bunch of files into the folder that I was trying to rename. Reading isn't an issue, we pull movies off of it all the time. Since the syslog gets wiped out on reboot I'm working on getting that setup to write to a file on flash (based on information found in other threads) so I can see if there's any errors etc... I can tell you there don't seem to be any related SMART errors on any of the drives. There's one High Fly Write on one of the Seagate's but that's been there from the very beginning and I don't see anything else occurring. Like I said, I am working on getting a copy of the syslog from the time of the reboot. I'm not looking for someone to do the leg work for me. But I just wanted to post the symptoms in case anyone has seen something similar, might have some troubleshooting steps that I haven't thought of, or may have an idea what might be going on (file system corruption?). It's difficult to troubleshoot because the array is pretty heavily used by my family. Also once something does occur I prefer to let the parity check complete which means a maximum of one troubleshooting step per night if it triggers a reboot. Thanks again. I would check the file-system on the specific disk for errors using reiserfsck. it is about the only thing I can think of that would result in a crash when re-naming a directory (Unless it is a user-shares issue in trying to stay in sync) I fully understand about it being difficult to take the array off-line once the family gets used to it being available... and there's just me and my wife!!! In any case, look here in the wiki for instructions on how to run a file-system check:http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems
April 7, 201016 yr Author Thanks Joe. I'll do the file system check and I may disable user shares as well temporarily to see if that makes a difference. There's not much that would need to be reworked if I disable user shares at this point. I'd like to reproduce it and get a syslog first if possible. Might be interesting to see what it says.
April 8, 201016 yr Author Well....I can verify the problem is still reproducible and syslog didn't help much. I tailed the log in a telnet window tail -f /var/log/syslog and nothing was added when the device restarted. The last entry was just my ROOT login. I also stopped the array, disabled user shares and started the array, and the reboot still happens when I try to rename the folder. I guess reiserfsck is next. PS - Other folders on the same disk share I can rename without issue.
April 8, 201016 yr Author OK. Looks like reiserfsck did find some things. Here's the output: root@Tower:~# reiserfsck /dev/md2 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md2 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Thu Apr 8 06:29:43 2010 ########### Replaying journal.. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed Checking internal tree../ 1 (of 7)/ 1 (of 163)/ 1 (of 87)bad_path: block 3 2770, pointer 0: The used space (4108) of the child block (8211) is not equal to the (blocksize (4096) - free space (44) - header size (24)) / 7 (of 7)/ 19 (of 136)/ 38 (of 86)bad_stat_data: The objectid (1265) is sha red by at least two files. Can be fixed with --rebuild-tree only. finished Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Checking Semantic tree: /Moviesvpf-10650: The directory [2 4] has the wrong size in the StatData (4856), should be (4848) finished 3 found corruptions can be fixed when running with --fix-fixable ########### reiserfsck finished at Thu Apr 8 06:39:06 2010 ########### root@Tower:~# It's recommending that I run with --fix-fixable and I also see one thing mentioned that it says can only be fixed with --rebuild-tree only. Do I just run those and deal with the fallout? Waiting for advice before proceeding.
April 8, 201016 yr OK. Looks like reiserfsck did find some things. Here's the output: root@Tower:~# reiserfsck /dev/md2 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md2 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Thu Apr 8 06:29:43 2010 ########### Replaying journal.. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed Checking internal tree../ 1 (of 7)/ 1 (of 163)/ 1 (of 87)bad_path: block 3 2770, pointer 0: The used space (4108) of the child block (8211) is not equal to the (blocksize (4096) - free space (44) - header size (24)) / 7 (of 7)/ 19 (of 136)/ 38 (of 86)bad_stat_data: The objectid (1265) is sha red by at least two files. Can be fixed with --rebuild-tree only. finished Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Checking Semantic tree: /Moviesvpf-10650: The directory [2 4] has the wrong size in the StatData (4856), should be (4848) finished 3 found corruptions can be fixed when running with --fix-fixable ########### reiserfsck finished at Thu Apr 8 06:39:06 2010 ########### root@Tower:~# It's recommending that I run with --fix-fixable and I also see one thing mentioned that it says can only be fixed with --rebuild-tree only. Do I just run those and deal with the fallout? Waiting for advice before proceeding. I would run --fix-fixable first... Then, odds are it will ask you to re-run it with --rebuild-tree. Joe L.
April 8, 201016 yr Author Thanks Joe. I ran with --fix-fixable and just wanted to make sure I need to proceed with --rebuild-tree. Here's the output from --fix-fixable: root@Tower:~# reiserfsck --fix-fixable /dev/md2 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check consistency of the filesystem on /dev/md2 and will fix what can be fixed without --rebuild-tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --fix-fixable started at Thu Apr 8 06:59:51 2010 ########### Replaying journal.. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed Checking internal tree../ 1 (of 7)/ 1 (of 163)/ 1 (of 87)bad_path: block 3 2770, pointer 0: The used space (4108) of the child block (8211) is not equal to the (blocksize (4096) - free space (44) - header size (24)) - corrected to (402 / 7 (of 7)/ 19 (of 136)/ 38 (of 86)bad_stat_data: The objectid (1265) is sha red by at least two files. Can be fixed with --rebuild-tree only. finished Comparing bitmaps..vpf-10630: The on-disk and the correct bitmaps differs. Will be fixed later. Checking Semantic tree: /Moviesvpf-10650: The directory [2 4] has the wrong size in the StatData (4856) - corrected to (4848) finished No corruptions found There are on the filesystem: Leaves 171551 Internal nodes 1100 Directories 162 Other files 1228 Data block pointers 173415243 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Thu Apr 8 07:29:41 2010 ########### root@Tower:~# It still mentions objectid 1265 is shared, but at the end it also says "No corruptions found". I just want to make sure before I proceed that I'm doing the right thing. Thanks
April 8, 201016 yr Thanks Joe. I ran with --fix-fixable and just wanted to make sure I need to proceed with --rebuild-tree. Here's the output from --fix-fixable: root@Tower:~# reiserfsck --fix-fixable /dev/md2 reiserfsck 3.6.19 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check consistency of the filesystem on /dev/md2 and will fix what can be fixed without --rebuild-tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --fix-fixable started at Thu Apr 8 06:59:51 2010 ########### Replaying journal.. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed Checking internal tree../ 1 (of 7)/ 1 (of 163)/ 1 (of 87)bad_path: block 3 2770, pointer 0: The used space (4108) of the child block (8211) is not equal to the (blocksize (4096) - free space (44) - header size (24)) - corrected to (402 / 7 (of 7)/ 19 (of 136)/ 38 (of 86)bad_stat_data: The objectid (1265) is sha red by at least two files. Can be fixed with --rebuild-tree only. finished Comparing bitmaps..vpf-10630: The on-disk and the correct bitmaps differs. Will be fixed later. Checking Semantic tree: /Moviesvpf-10650: The directory [2 4] has the wrong size in the StatData (4856) - corrected to (4848) finished No corruptions found There are on the filesystem: Leaves 171551 Internal nodes 1100 Directories 162 Other files 1228 Data block pointers 173415243 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Thu Apr 8 07:29:41 2010 ########### root@Tower:~# It still mentions objectid 1265 is shared, but at the end it also says "No corruptions found". I just want to make sure before I proceed that I'm doing the right thing. Thanks I would first try just reiserfsck --check /dev/md2 and if it says to use rebuild-tree, go ahead and do as it instructs. Joe L.
April 9, 201016 yr Author Thanks for helping me through this Joe. The steps are well documented, but it's always nice to have someone with experience confirm. I did end up doing the --rebuild-tree and everything looks good now with a final --check. In the lost+found I only found one movie that actually looks complete. I won't know for sure until I play it. But it looks like at worst I'll have to re-rip one movie. Thanks again for your time.
Archived
This topic is now archived and is closed to further replies.