October 20, 201015 yr Hey all, I was accessing one of my shares today and noticed that it was completely empty. So I navigated to the Disk share and there were some files in there, but I believe some were missing. I went to unMENU after I clicked stopped to bring the array down and noticed some serious errors going on here and the system is hanging while trying to stop the drives. What do I do?!?!?! syslog-2010-10-21.zip
October 20, 201015 yr Author Well I rebooted (hard) and it's doing a parity check... hopefully this works out!
October 20, 201015 yr Your disk2 has some file-system corruption. These messages in your syslog showed how it was mounted as read-only to prevent further corruption. Oct 21 01:10:44 Tower kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 19475 does not match to the expected one 3 Oct 21 01:10:44 Tower kernel: REISERFS error (device md2): vs-5150 search_by_key: invalid format found in block 89452437. Fsck? Oct 21 01:10:44 Tower kernel: REISERFS (device md2): Remounting filesystem read-only Oct 21 01:10:44 Tower kernel: REISERFS error (device md2): zam-7001 reiserfs_find_entry: io error Oct 21 01:10:44 Tower kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 19475 does not match to the expected one 3 Oct 21 01:10:44 Tower kernel: REISERFS error (device md2): vs-5150 search_by_key: invalid format found in block 89452437. Fsck? Oct 21 01:10:44 Tower kernel: REISERFS error (device md2): zam-7001 reiserfs_find_entry: io error Oct 21 01:10:44 Tower kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 19475 does not match to the expected one 3 Oct 21 01:10:44 Tower kernel: REISERFS error (device md2): vs-5150 search_by_key: invalid format found in block 89452437. Fsck? Oct 21 01:10:44 Tower kernel: REISERFS error (device md2): zam-7001 reiserfs_find_entry: io error You'll need to follow the instructions in the wiki to check and repair the file-system on /dev/md2 before you'll stop seeing the errors: http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems
October 20, 201015 yr Joe, Should I let this parity check finish first or stop it? It does not matter. You can let it continue.
October 20, 201015 yr Author Looks like I'm all good?? No corruptions found There are on the filesystem: Leaves 361477 Internal nodes 2155 Directories 134 Other files 364 Data block pointers 365769727 (227042 of them are zero) Safe links 0
October 20, 201015 yr Looks like I'm all good?? No corruptions found There are on the filesystem: Leaves 361477 Internal nodes 2155 Directories 134 Other files 364 Data block pointers 365769727 (227042 of them are zero) Safe links 0 If it found no errors I'd perform a memory check. Something caused the initial errors "detected" in the file-system so it made it read-only, and it could easily be the memory.
October 20, 201015 yr Author Oh crap.. I just followed this: mount /dev/md1 /mnt/disk1 [important to match up the 'md1' with 'disk1', 'md2' with 'disk2', etc.] /usr/sbin/smbd -D /usr/sbin/nmbd -D [all shares should again be visible] But changed it to disk2 and now my disk2 is a mirror of disk1... oh no!
October 20, 201015 yr Author I screwed up because i did this mount /dev/md1 /mnt/disk2 When it should have been: mount /dev/md2 /mnt/disk2
October 20, 201015 yr Author What do I do now?!?! Holding as I don't want to screw up any further. I didn't notice that mount md1 part!! UGH
October 20, 201015 yr I screwed up because i did this mount /dev/md1 /mnt/disk2 then type umount /mnt/disk2 and then re-type the correct mount command. mount /dev/md2 /mnt/disk2
October 20, 201015 yr Author OH THANK GOD!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I almost cried. Ok- so I should do a memory check after a reboot and run it before unRAID OS boots, correct?
October 20, 201015 yr OH THANK GOD!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I almost cried. Ok- so I should do a memory check after a reboot and run it before unRAID OS boots, correct? correct.
October 20, 201015 yr Author Joe, Thank you again. I forgot to say that before. Question on the Memtest: How many tests does it run through and how long does it usually take? I'm running it now and it doesn't seem to say how many total tests until it's finished. Thank you,
October 21, 201015 yr Author Well the memtest ran all night long and did not find any errors at all... I have no idea what could have happened. I guess I will keep a very close eye on the system log and report back. Thank you,
October 25, 201015 yr Author Well there is definitely something acting strange with my server. I posted a new log after I rebooted... What are these: Oct 26 02:01:48 Tower kernel: REISERFS (device md1): journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md1): checking transaction log (md1) Oct 26 02:01:48 Tower kernel: REISERFS (device md15): journal params: device md15, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md15): checking transaction log (md15) Oct 26 02:01:48 Tower kernel: REISERFS (device md9): journal params: device md9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md9): checking transaction log (md9) Oct 26 02:01:48 Tower kernel: REISERFS (device md14): journal params: device md14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md14): checking transaction log (md14) Oct 26 02:01:48 Tower kernel: REISERFS (device md7): journal params: device md7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md7): checking transaction log (md7) Oct 26 02:01:48 Tower kernel: REISERFS (device md6): journal params: device md6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 syslog-2010-10-26.txt
October 25, 201015 yr Well there is definitely something acting strange with my server. I posted a new log after I rebooted... What are these: Oct 26 02:01:48 Tower kernel: REISERFS (device md1): journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md1): checking transaction log (md1) Oct 26 02:01:48 Tower kernel: REISERFS (device md15): journal params: device md15, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md15): checking transaction log (md15) Oct 26 02:01:48 Tower kernel: REISERFS (device md9): journal params: device md9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md9): checking transaction log (md9) Oct 26 02:01:48 Tower kernel: REISERFS (device md14): journal params: device md14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md14): checking transaction log (md14) Oct 26 02:01:48 Tower kernel: REISERFS (device md7): journal params: device md7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 26 02:01:48 Tower kernel: REISERFS (device md7): checking transaction log (md7) Oct 26 02:01:48 Tower kernel: REISERFS (device md6): journal params: device md6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 These messages are from the ReiserFS cleaning up after itself by running through journal entries it has not committed. The ReiserFS is a Journaling File System, which keeps track of the changes it intends to make in a journal before committing them to the main file system. In the event of a system crash or power failure, such file systems are quicker to bring back online and less likely to become corrupted. See http://en.wikipedia.org/wiki/Journaling_file_system for background information. It is not unusual to see journal entries being played after an unclean shutdown. Did you power down unRAID cleanly before the reboot?
Archived
This topic is now archived and is closed to further replies.