Treytor Posted January 20, 2011 Author Share Posted January 20, 2011 Am I missing something obvious with running this command? I'm assuming it's good to try this straight from prompt after boot? You said it "must be run on the "md" device", does this just mean to use md7 instead of sdg? Or do I need to execute it from somewhere other than root prompt? Thanks again. You have a Norco case and they use a backplanes. There is a chance that you may have a faulty one (cracked trace, etc.) I will suggest for you to identify the suspect drives and to move them around - to see if the errors will move with the drives. Since you have only 18 drives you have the two other drive slots available and you already have the necessary cables to perform this test. I will try moving the drives, but I suspect this is not the case as these are the exact same drives that caused me to rebuild in the first place (in addition to other drives erroring randomly, etc...) Link to comment
Joe L. Posted January 20, 2011 Share Posted January 20, 2011 Am I missing something obvious with running this command? I'm assuming it's good to try this straight from prompt after boot?It is good to run it at the "root" prompt right after booting. You do not need to be anywhere special. You said it "must be run on the "md" device", does this just mean to use md7 instead of sdg? Or do I need to execute it from somewhere other than root prompt? Thanks again. Well, to keep parity correct it is proper to run the command on the /dev/mdX device. Since you are not operational at this time, you can give a try running reiserfsck --check /dev/sdg1 (note there is a trailing 1, since you are checking the first partition on the disk) and reiserfsck --check /dev/sdp1 (again, note there is a trailing 1, since you are checking the first partition on the disk) See if then still complains about a missing superblock. If by some miracle they succeed, you can think about running the repair on the /dev/sdg1 ad /dev/sdp1 devices. You'll trash parity that way, and you'll need to do a full parity check once the repair is complete, and it will find and fix the parity disk to be in step with the data disks. Joe L. Link to comment
Treytor Posted January 20, 2011 Author Share Posted January 20, 2011 Just moved the drives, and the same thing is happening. Link to comment
Treytor Posted January 20, 2011 Author Share Posted January 20, 2011 Progress! (because I moved the drives, their designation has changed): root@Cooper:~# reiserfsck --check /dev/sdh1 reiserfsck 3.6.21 (2009 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/sdh1 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 Jan 20 13:04:03 2011 ########### Replaying journal: Trans replayed: mountid 19, transid 103, desc 889, len 1, commit 891, next trans offset 874 Trans replayed: mountid 19, transid 104, desc 892, len 1, commit 894, next trans offset 877 Replaying journal: Done. Reiserfs journal '/dev/sdh1' in blocks [18..8211]: 2 transactions replayed Checking internal tree.. finished Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Checking Semantic tree: finished 1 found corruptions can be fixed when running with --fix-fixable ########### reiserfsck finished at Thu Jan 20 13:05:54 2011 ########### root@Cooper:~# reiserfsck --check /dev/sdg1 reiserfsck 3.6.21 (2009 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/sdg1 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 Jan 20 13:07:06 2011 ########### Replaying journal: Done. Reiserfs journal '/dev/sdg1' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 92255 Internal nodes 569 Directories 978 Other files 31240 Data block pointers 91657293 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Thu Jan 20 13:07:24 2011 ########### root@Cooper:~# Running --fix-fixable on the first drive now. EDIT: Okay that's done. Still showing up as orange / red in the web admin though. Gonna move them back to their designated spots. Replaying journal: Done. Reiserfs journal '/dev/sdh1' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..vpf-10630: The on-disk and the correct bitmaps differs. Will be fixed later. Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 282 Internal nodes 3 Directories 9 Other files 20 Data block pointers 280768 (18599 of them are zero) Safe links 0 ########### reiserfsck finished at Thu Jan 20 13:12:10 2011 Link to comment
lionelhutz Posted January 20, 2011 Share Posted January 20, 2011 It's good to see that the sdX devices are working but any disk changes will damage your parity. With the bad blocks on disk9 you'll likely lose some disk9 data. If disk9 completely dies before you get the parity sync'd again you'll likely lose all the data. I was going to recommend possibly writing zero's to the superblock but it's probably too late to bother now. Peter Link to comment
Treytor Posted January 20, 2011 Author Share Posted January 20, 2011 Here's the latest system log and smart data on the 2 drives in question: root@Cooper:~# smartctl -d ata -a /dev/sdg smartctl version 5.38 [i486-slackware-linux-gnu] Copyright © 2002-8 Bruce Alle n Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Second Generation Serial ATA family Device Model: WDC WD5000AAJS-22TKA0 Serial Number: WD-WCAPW5449900 Firmware Version: 12.01C01 User Capacity: 500,107,862,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Thu Jan 20 13:25:58 2011 PST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (12000) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off supp ort. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 150) minutes. Conveyance self-test routine recommended polling time: ( 6) minutes. SCT capabilities: (0x303f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_ FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0003 178 176 021 Pre-fail Always - 6075 4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1897 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always - 0 9 Power_On_Hours 0x0032 074 074 000 Old_age Always - 19156 10 Spin_Retry_Count 0x0012 100 100 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0012 100 100 051 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 282 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 199 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 1899 194 Temperature_Celsius 0x0022 115 078 000 Old_age Always - 35 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 2464 200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. root@Cooper:~# smartctl -d ata -a /dev/sdp smartctl version 5.38 [i486-slackware-linux-gnu] Copyright © 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: WDC WD15EADS-00S2B0 Serial Number: WD-WCAVY0907597 Firmware Version: 04.05G04 User Capacity: 1,500,301,910,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Thu Jan 20 13:26:12 2011 PST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (28860) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 255) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x303f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 2 3 Spin_Up_Time 0x0027 142 139 021 Pre-fail Always - 9883 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 992 5 Reallocated_Sector_Ct 0x0033 199 199 140 Pre-fail Always - 3 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 087 087 000 Old_age Always - 9691 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 100 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 42 193 Load_Cycle_Count 0x0032 182 182 000 Old_age Always - 54358 194 Temperature_Celsius 0x0022 119 074 000 Old_age Always - 33 196 Reallocated_Event_Count 0x0032 198 198 000 Old_age Always - 2 197 Current_Pending_Sector 0x0032 195 195 000 Old_age Always - 1311 198 Offline_Uncorrectable 0x0030 195 195 000 Old_age Offline - 1301 199 UDMA_CRC_Error_Count 0x0032 200 192 000 Old_age Always - 29512 200 Multi_Zone_Error_Rate 0x0008 001 001 000 Old_age Offline - 114056 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. root@Cooper:~# I don't see that pending error any more. syslog2.txt Link to comment
Treytor Posted January 20, 2011 Author Share Posted January 20, 2011 Everything *seems* to be okay on the hardware side now. But I'm unclear what to do next. Should I try rebuilding the superblock like Joe instructed, but running it on sdg1 and sdp1 instead? Link to comment
Joe L. Posted January 20, 2011 Share Posted January 20, 2011 Everything *seems* to be okay on the hardware side now. But I'm unclear what to do next. Should I try rebuilding the superblock like Joe instructed, but running it on sdg1 and sdp1 instead? No... because the --check does not instruct you to. It appears as if the file systems are ok now. Unless I mis-understood what you've done. Basically, it sounds as if your backplane was causing the errors. Link to comment
Treytor Posted January 20, 2011 Author Share Posted January 20, 2011 No, because I moved the drives and still had the same problem. While in their new location I ran the --check (on sdX1) and then did as instructed for one of the drives. The other checked out okay. I have since moved them back and we are getting positive smart checks from the drives now in their "original" locations. We aren't seeing the problems as before. I believe the superblock still needs to be rebuilt, however? Link to comment
prostuff1 Posted January 20, 2011 Share Posted January 20, 2011 I believe the superblock still needs to be rebuilt, however? If it does not tell you it needs to be then you probably do not have to. Link to comment
Treytor Posted January 20, 2011 Author Share Posted January 20, 2011 Well if I run reiserfsck --check /dev/md7, I get this: bread: Cannot read the block (2): (Input/output error). If I run reiserfsck --check /dev/sdg1, it works: ########### reiserfsck --check started at Thu Jan 20 13:49:29 2011 ########### Replaying journal: Done. Reiserfs journal '/dev/sdg1' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 92255 Internal nodes 569 Directories 978 Other files 31240 Data block pointers 91657293 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Thu Jan 20 13:50:57 2011 ########### I have confirmed that these are the same drive. The system.log says the superblock is bad: Jan 20 13:21:45 Cooper emhttp: disk7 mount error: 32 Jan 20 13:21:45 Cooper emhttp: shcmd (58): rmdir /mnt/disk7 Jan 20 13:21:45 Cooper kernel: REISERFS warning (device md9): sh-2006 read_super_block: bread failed (dev md9, block 2, size 4096) Jan 20 13:21:45 Cooper kernel: REISERFS warning (device md9): sh-2006 read_super_block: bread failed (dev md9, block 16, size 4096) Jan 20 13:21:45 Cooper kernel: REISERFS warning (device md9): sh-2021 reiserfs_fill_super: can not find reiserfs on md9 Jan 20 13:21:45 Cooper kernel: REISERFS warning (device md7): sh-2006 read_super_block: bread failed (dev md7, block 2, size 4096) Jan 20 13:21:45 Cooper kernel: REISERFS warning (device md7): sh-2006 read_super_block: bread failed (dev md7, block 16, size 4096) Jan 20 13:21:45 Cooper kernel: REISERFS warning (device md7): sh-2021 reiserfs_fill_super: can not find reiserfs on md7 Link to comment
Joe L. Posted January 20, 2011 Share Posted January 20, 2011 power down. Reboot. Then try. Link to comment
Treytor Posted January 20, 2011 Author Share Posted January 20, 2011 Done, nothing has changed. Granted I have very little knowledge of the inner workings of linux file systems, paritions, and mounting drives, but it seems to me something is messed up with the partition on each drive. Specifying the partition everything looks good, but the drive is coming up with nothing. Should I try repairing the superblock by specifying the partition? Link to comment
Joe L. Posted January 20, 2011 Share Posted January 20, 2011 Done, nothing has changed. Granted I have very little knowledge of the inner workings of linux file systems, paritions, and mounting drives, but it seems to me something is messed up with the partition on each drive. Specifying the partition everything looks good, but the drive is coming up with nothing. Should I try repairing the superblock by specifying the partition? No... not unless the immediately previous reiserfsck --check or --fix-fixable requests you do so. If it did, then yes. Link to comment
Treytor Posted January 21, 2011 Author Share Posted January 21, 2011 Alright, well here is my latest system log, and am open to any suggestions on how to proceed. syslog.txt Link to comment
Treytor Posted January 21, 2011 Author Share Posted January 21, 2011 New day... let's start over. I have 2 drives that appear to be okay when scanned with reiserfsck, but ONLY if the partition is specified: reiserfsck --check /dev/sdp1 Reiserfsck does not instruct me to do anything further. If I scan the same drive, but as specified in the wiki: reiserfsck --check /dev/md7 I get: bread: Cannot read the block (2): (Input/output error). Because of this, I am assuming, unraid cannot mount the drives and shows them as unformatted. My syslog says this about the drives: Jan 20 14:04:49 Cooper logger: mount: wrong fs type, bad option, bad superblock on /dev/md7, Jan 20 14:04:49 Cooper logger: missing codepage or helper program, or other error Jan 20 14:04:49 Cooper logger: In some cases useful info is found in syslog - try Jan 20 14:04:49 Cooper logger: dmesg | tail or so Jan 20 14:04:49 Cooper logger: Jan 20 14:04:49 Cooper emhttp: _shcmd: shcmd (40): exit status: 32 Jan 20 14:04:49 Cooper emhttp: disk7 mount error: 32 Jan 20 14:04:49 Cooper emhttp: shcmd (41): rmdir /mnt/disk7 Jan 20 14:04:49 Cooper emhttp: shcmd (42): set -o pipefail ; mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md11 /mnt/disk11 2>&1 | logger Jan 20 14:04:49 Cooper logger: mount: wrong fs type, bad option, bad superblock on /dev/md9, Jan 20 14:04:49 Cooper logger: missing codepage or helper program, or other error Jan 20 14:04:49 Cooper logger: In some cases useful info is found in syslog - try Jan 20 14:04:49 Cooper logger: dmesg | tail or so Jan 20 14:04:49 Cooper logger: Jan 20 14:04:49 Cooper emhttp: _shcmd: shcmd (43): exit status: 32 Jan 20 14:04:49 Cooper emhttp: disk9 mount error: 32 Jan 20 14:04:49 Cooper emhttp: shcmd (44): rmdir /mnt/disk9 Jan 20 14:04:49 Cooper kernel: REISERFS warning (device md7): sh-2006 read_super_block: bread failed (dev md7, block 2, size 4096) Jan 20 14:04:49 Cooper kernel: REISERFS warning (device md7): sh-2006 read_super_block: bread failed (dev md7, block 16, size 4096) Jan 20 14:04:49 Cooper kernel: REISERFS warning (device md7): sh-2021 reiserfs_fill_super: can not find reiserfs on md7 Jan 20 14:04:49 Cooper kernel: REISERFS warning (device md9): sh-2006 read_super_block: bread failed (dev md9, block 2, size 4096) Jan 20 14:04:49 Cooper kernel: REISERFS warning (device md9): sh-2006 read_super_block: bread failed (dev md9, block 16, size 4096) Jan 20 14:04:49 Cooper kernel: REISERFS warning (device md9): sh-2021 reiserfs_fill_super: can not find reiserfs on md9 Jan 20 14:04:49 Cooper kernel: md: recovery thread has nothing to resync Is there anything I can do to try and bring these drives back online? Or will I have to format them? Thanks! Link to comment
limetech Posted January 21, 2011 Share Posted January 21, 2011 If you mount the partition manually, do all your files appear to be there? For example, from console or telnet: mkdir /x mount /dev/sdp1 /x ls /x Link to comment
Joe L. Posted January 21, 2011 Share Posted January 21, 2011 Well... If reiserfsck finds nothing wrong when you check the partition, then odds are nothing is wrong. I've never seen it say there was something correct when it was not. You MUST supply the partition when checking the file system in it, so that is very correct and normal. It is not normal for unRAID to not be able to connect to the exact same disk through the "md" device. It may have something to do with it having two disabled disks. At this point, I would like to ask you to perform a memory test... Just in case it is the root cause. At the same time, I'll send Tom@lime-tech a PM asking him to look at your system logs. He may see something. Odds are very good that since the reiserfsck comes back good, the data on those disks will still be there. Do not format them just yet. Joe L. Link to comment
Joe L. Posted January 21, 2011 Share Posted January 21, 2011 If you mount the partition manually, do all your files appear to be there? For example, from console or telnet: mkdir /x mount /dev/sdp1 /x ls /x I didn't send the PM yet... Wait for your cue... Glad you are looking at this Tom. It is really interesting, and confusing... Joe L. Link to comment
Treytor Posted January 21, 2011 Author Share Posted January 21, 2011 If you mount the partition manually, do all your files appear to be there? For example, from console or telnet: mkdir /x mount /dev/sdp1 /x ls /x Thanks for responding, and I had actually thought to try something very similar to this by trying "mount /dev/sdg1 /mnt/disk7" but that didn't work. Anyway, here's what we've got: root@Cooper:~# mkdir /x root@Cooper:~# mount /dev/sdp1 /x mount: /dev/sdp1 already mounted or /x busy root@Cooper:~# mount /dev/sdg1 /x mount: /dev/sdg1 already mounted or /x busy root@Cooper:~# ls /x root@Cooper:~# How do I list the currently active mounts? Link to comment
Treytor Posted January 21, 2011 Author Share Posted January 21, 2011 At this point, I would like to ask you to perform a memory test... Just in case it is the root cause. I did an extensive memory test before even booting unraid after the intial build. Everything checks out. Link to comment
Joe L. Posted January 21, 2011 Share Posted January 21, 2011 you type mount But it might not be "mounted", but instead locked by the "md" device from being mounted directly. Joe L. Link to comment
Treytor Posted January 21, 2011 Author Share Posted January 21, 2011 root@Cooper:~# mount fusectl on /sys/fs/fuse/connections type fusectl (rw) usbfs on /proc/bus/usb type usbfs (rw) /dev/sda1 on /boot type vfat (rw,noatime,nodiratime,umask=0,shortname=mixed) /dev/md15 on /mnt/disk15 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md17 on /mnt/disk17 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md16 on /mnt/disk16 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md13 on /mnt/disk13 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md14 on /mnt/disk14 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md8 on /mnt/disk8 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md5 on /mnt/disk5 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md6 on /mnt/disk6 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md12 on /mnt/disk12 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md1 on /mnt/disk1 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md4 on /mnt/disk4 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md10 on /mnt/disk10 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md3 on /mnt/disk3 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md11 on /mnt/disk11 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) /dev/md2 on /mnt/disk2 type reiserfs (rw,noatime,nodiratime,noacl,nouser_xattr) shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other,default_permissions) Link to comment
Joe L. Posted January 21, 2011 Share Posted January 21, 2011 At this point, I would like to ask you to perform a memory test... Just in case it is the root cause. I did an extensive memory test before even booting unraid after the intial build. Everything checks out. OK, but memory has been known to go bad... and I did not want to overlook anything. Joe L. Link to comment
bcbgboy13 Posted January 21, 2011 Share Posted January 21, 2011 If nothing else work I will propose to use the "brute force" approach before reformat. You have Norco so the disks in questions are easy to remove. Attach them (one at a time) to a Windows computer and use Yareg - http://yareg.akucom.de/ Very interesting "news" there from November 7th, 2010 - apparently some people are using it for "data-recovery" of ReiserFS partitioned NAS disks (not physically damaged) so you have nothing to lose. Again - if Tom and Joe L. suggestions do not work. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.