Spencer Posted May 12, 2015 Share Posted May 12, 2015 I get the following error message after a reboot: stat: cannot stat '/usr/local/emhttp/mnt/cache*' sylog.zip attached syslog.zip Link to comment
trurl Posted May 12, 2015 Share Posted May 12, 2015 Do you have a cache drive? Is it sdf? Post a screenshot showing sdf. Link to comment
Spencer Posted May 12, 2015 Author Share Posted May 12, 2015 Requested screen capture from the unRAID gui. Link to comment
RobJ Posted May 13, 2015 Share Posted May 13, 2015 I'll try tomorrow, when I'm less tired, with a chronology. There's something wrong with that Cache drive, way back on May 6, but I really don't understand why unRAID didn't inform you of that back then. It's been unresponsive almost from the start. Link to comment
Spencer Posted May 13, 2015 Author Share Posted May 13, 2015 The motherboard has 4 sata ports. They control the parity disk and the 3 data disks. I am using an IOCrest PCI Express card - Model SI-PEX40064 - on the strength of an Amazon reviewer stating that it was plug and play with his unRAID server. Link to comment
Spencer Posted May 15, 2015 Author Share Posted May 15, 2015 Any help? Or should I submit it directly? Link to comment
RobJ Posted May 15, 2015 Share Posted May 15, 2015 Any help? Or should I submit it directly? I apologize, I forgot! And been a little busy... It's possible that Tom should take a look, but first you should make sure the drive isn't bad. May 6 12:18:54 Tower kernel: ata8: link is slow to respond, please be patient (ready=0) May 6 12:18:54 Tower kernel: ata8: softreset failed (device not ready) May 6 12:18:54 Tower kernel: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300) May 6 12:18:54 Tower kernel: ata8.00: qc timeout (cmd 0xec) May 6 12:18:54 Tower kernel: ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4) May 6 12:18:54 Tower kernel: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300) May 6 12:18:54 Tower kernel: ata8.00: qc timeout (cmd 0xec) May 6 12:18:54 Tower kernel: ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4) May 6 12:18:54 Tower kernel: ata8: limiting SATA link speed to 3.0 Gbps May 6 12:18:54 Tower kernel: ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 320) May 6 12:18:54 Tower kernel: ata8.00: ATA-9: ST1000DM003-1ER162, Z4Y5QJ4M, CC45, max UDMA/133 May 6 12:18:54 Tower kernel: ata8.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA May 6 12:18:54 Tower kernel: ata8.00: configured for UDMA/133 May 6 12:18:54 Tower kernel: scsi 8:0:0:0: Direct-Access ATA ST1000DM003-1ER1 CC45 PQ: 0 ANSI: 5 May 6 12:18:54 Tower kernel: sd 8:0:0:0: Attached scsi generic sg5 type 0 May 6 12:18:54 Tower kernel: sd 8:0:0:0: [sdf] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) May 6 12:18:54 Tower kernel: sd 8:0:0:0: [sdf] 4096-byte physical blocks May 6 12:18:54 Tower kernel: sd 8:0:0:0: [sdf] Write Protect is off May 6 12:18:54 Tower kernel: sd 8:0:0:0: [sdf] Mode Sense: 00 3a 00 00 May 6 12:18:54 Tower kernel: sd 8:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA May 6 12:18:54 Tower kernel: sdf: sdf1 May 6 12:18:54 Tower kernel: sd 8:0:0:0: [sdf] Attached SCSI disk Right from the start, it had trouble. Once the SATA link was established, it was at 6.0 Gbps, so it's clearly capable of that, but it couldn't communicate at that speed. Once slowed to 3.0 Gbps, it was able to identify itself, and one partition was found. You started the array, with no Cache drive assigned, so stopped it, assigned sdf as the Cache drive and started the array. But ... May 6 12:21:12 Tower emhttp: shcmd (250): mkdir -p /mnt/cache May 6 12:21:12 Tower emhttp: shcmd (251): set -o pipefail ; mount -t auto -o noatime,nodiratime /dev/sdf1 /mnt/cache |& logger May 6 12:21:12 Tower logger: mount: block device /dev/sdf1 is write-protected, mounting read-only May 6 12:21:12 Tower kernel: REISERFS warning (device sdf1): sh-2021 reiserfs_fill_super: can not find reiserfs on sdf1 May 6 12:21:12 Tower kernel: EXT3-fs (sdf1): error: can't find ext3 filesystem on dev sdf1. May 6 12:21:12 Tower kernel: EXT2-fs (sdf1): error: can't find an ext2 filesystem on dev sdf1. May 6 12:21:12 Tower kernel: EXT4-fs (sdf1): VFS: Can't find ext4 filesystem May 6 12:21:12 Tower kernel: FAT-fs (sdf1): bogus number of reserved sectors May 6 12:21:12 Tower kernel: FAT-fs (sdf1): Can't find a valid FAT filesystem May 6 12:21:12 Tower kernel: FAT-fs (sdf1): bogus number of reserved sectors May 6 12:21:12 Tower kernel: FAT-fs (sdf1): Can't find a valid FAT filesystem May 6 12:21:13 Tower kernel: REISERFS warning (device sdf1): sh-2021 reiserfs_fill_super: can not find reiserfs on sdf1 May 6 12:21:13 Tower kernel: EXT3-fs (sdf1): error: can't find ext3 filesystem on dev sdf1. May 6 12:21:13 Tower kernel: EXT2-fs (sdf1): error: can't find an ext2 filesystem on dev sdf1. May 6 12:21:13 Tower kernel: EXT4-fs (sdf1): VFS: Can't find ext4 filesystem May 6 12:21:13 Tower kernel: FAT-fs (sdf1): bogus number of reserved sectors May 6 12:21:13 Tower kernel: FAT-fs (sdf1): Can't find a valid FAT filesystem May 6 12:21:13 Tower kernel: FAT-fs (sdf1): bogus number of reserved sectors May 6 12:21:13 Tower kernel: FAT-fs (sdf1): Can't find a valid FAT filesystem May 6 12:21:13 Tower kernel: ISOFS: Unable to identify CD-ROM format. May 6 12:21:13 Tower kernel: hfsplus: unable to find HFS+ superblock May 6 12:21:13 Tower kernel: UDF-fs: warning (device sdf1): udf_load_vrs: No VRS found May 6 12:21:13 Tower kernel: UDF-fs: warning (device sdf1): udf_fill_super: No partition found (2) May 6 12:21:13 Tower kernel: XFS (sdf1): Invalid superblock magic number May 6 12:21:13 Tower logger: mount: you must specify the filesystem type May 6 12:21:13 Tower emhttp: shcmd: shcmd (251): exit status: 32 May 6 12:21:13 Tower emhttp: mount error: No file system (32) May 6 12:21:13 Tower emhttp: shcmd (252): rmdir /mnt/cache It tested a bunch of file systems, all failed. It started by discovering a read-only partition, which seemed to throw it off, something it did not expect. Later, it tried to prepare the drive, write a new MBR, but appears to have failed miserably, even on repeated attempts to write to the drive. It bothers me how much it tried to do various tasks on the drive, as if it wasn't checking error returns at all! Later it sets up the Mover to run, as if there is a valid Cache drive! The Mover runs over and over, failing each time. Perhaps Tom should have a look at that, the error checking. In my experience, it's best to check every error return involving disk I/O, no matter how trivial or certain to succeed, because you never know when the drive could stop responding. My recommendation is to unassign and Preclear that drive, after checking the connections to it. Do you happen to know whether this drive is good or not? You also might want to test it on an onboard SATA port, and test a known good drive on the addon card, to make sure you have a good usable SATA card. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.