Jump to content

Fresh set of eyes on my logs


Recommended Posts

SuperOrb runs a system very similar to mine.  His logs are, to say the least, so much "cleaner" than mine.  He doesn't have any AHCI / UDMA/133 links going on either.  I do, and pretty much every drive.  I've tried to swap the cable today, with no success.  Now, with that said though, it's looked like this since day 1 now that I think about it, but, I've ignored it.  Getting only 15-18MB writes (to protected array) however, are ridiculous and gaining annoyance now.

 

I'd love to resolve the issue with the hardware I have, despite my desires to eventually upgrade the mobo/cpu/ecc ram (not to mention controller cards) but, that would essentially be a new system less case, p/s and drives.  TBH, I may just build an entirely new unRAID (have a pro key on standby anyway) if I end up doing that, which would make getting this system squared away, essential.

 

I'd like to ask for a fresh set of eyes on this.  AHCI is enabled on the SATA controllers via the mobo BIOS.  Whether or not it's actually WORKING though remains to be seen.

 

Toshiba 43NPEW7YS (sdc) is my Parity, it is on a mobo SATA2 port.  My unused cache and open port on the Sil3132 card (yeah, I know, I was just made aware of this cards issues, which I guess were unknown at the time of the build, so perhaps a good thing I never enabled the cache drive).  I admit, I am not aware of how one finds out which drives are on what other mobo ports (without shutting down and looking at serial numbers, which I will do after this 1.2 TB move is done --- at 16MB/s average though, I may see New Years before it finishes <grin>).

 

Attached is the log.  Any and all help from all those that are knowledgeable is appreciated.

unraid_log_06052014.txt

Link to comment

Let me add, the smart report from all drives are fine, with the exception of the Parity, which has UDMA CRC errors in its smart from before I replaced the reverse breakout (running a Norco 4224) cable, all has been well with the parity there after, I think, unless it too is showing UDMA/133, which I believe it is not (I get protected write speeds up to 55MB/s at times, depending on the data drive being written to that is).

 

Link to comment

                                        Write  Read

parity    Toshiba_W7YS

disk1    wd20ears_3282    38    65

disk2    wd20ears_1059    35    65

disk3    Toshiba_93YS        42    65

disk4    Hitachi_WPJD          42    65

disk5    wd20ears_7198      13    68 (makes perfect sense right? sigh)

disk6    Hitach_RH6D          38      70

disk7    Toshiba_NHYS        60      70

disk8    Hitachi_SVMD          30      70

disk9    wd20ears_4093      13      65

disk10  Toshiba_8GXS        56      71

disk11  Toshiba_K7YS          40    72

 

 

I guess the problem is just with the oldest wd20ears drives, that or something else.  I have three 3TB drives precleared on standby, so after this parity check I'm going to physically replace the second slow write wd20ears (because it has less data on it) with one of the retail 3TB deskstar(s) to see how it does with writes then.  If it's slow, I'll have to assume backplane or controller.  ?

Link to comment

Memtest at 24 hour mark, at least 24 more to go, no errors thus far.  I guess the slow write speeds to the wd20ears are due to age, or something.  I'd say because they are showing as UDMA/133 in the logs, but, some of the ones with write speeds of 38 up to 60 are showing as UDMA/133 as well if I'm not mistaken.  It seems too I have an issue of 2 sectors giving parity sync errors, each time they are 8 sectors apart, but, different locations after each correction.  Superorb had this issue with the random sync errors (though, I believe he had far more than 2 sectors giving errors) and it turned out to be the mobo sata port(s).  I consequently have the same mobo, so maybe that is my issue as well.  The showing of the drives linking at only UDMA/133 and apparent lack of AHCI is still somewhat concerning.  Since my second unRAID uses ECC, I've been wanting to make this one ECC for awhile, I suppose a mobo, cpu and ram change out may be in order.

 

Updating the page as time and actions go by, though, I'd still appreciate it very much if a fresh set of eyes could look at the logs and pull out the concerns, give suggestions, etc.  My BIOS configuration is the same as Superorb's, though he uses the m1015 and me two of the Supermicro PCIex4 (SATA not SATA2) cards.  His logs are so much "cleaner" and shows SATA linking and AHCI.  I'll let him share his logs if he wants.

Link to comment

Your log looks pretty clean to me.  It looks very similar to mine.  I know the 2TB drives compared to 3-4TB drives are much slower and drag down the whole system.  I found 2 things that really increased speed, 1 is the tuneables script for setting the md parameters:

 

http://lime-technology.com/forum/index.php?topic=29009.0

 

And for really boosting write performance is the reconstructive write setting, "mdcmd set md_write_method 1".  It does power up all disks during write operations, but does boost write speed alot.

 

Here are some benchmarks from my one unraid server with a few 2TB drives before and after the tuning script:

 

-----------------------------------------------------------------------

CrystalDiskMark 3.0.3 x64 © 2007-2013 hiyohiyo

                          Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 byte/s [sATA/300 = 300,000,000 byte/s]

 

          Sequential Read :  101.155 MB/s

          Sequential Write :    36.237 MB/s

        Random Read 512KB :    83.262 MB/s

        Random Write 512KB :    37.948 MB/s

    Random Read 4KB (QD=1) :    1.464 MB/s [  357.5 IOPS]

  Random Write 4KB (QD=1) :    1.228 MB/s [  299.8 IOPS]

  Random Read 4KB (QD=32) :    82.391 MB/s [ 20115.0 IOPS]

  Random Write 4KB (QD=32) :    29.448 MB/s [  7189.5 IOPS]

 

  Test : 1000 MB [Y: 27.2% (4552.6/16766.6 GB)] (x5)

  Date : 2014/06/01 9:56:16

    OS : Windows 8.1  [6.3 Build 9600] (x64)

 

After tuning:

 

-----------------------------------------------------------------------

CrystalDiskMark 3.0.3 x64 © 2007-2013 hiyohiyo

                          Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 byte/s [sATA/300 = 300,000,000 byte/s]

 

          Sequential Read :  113.127 MB/s

          Sequential Write :    48.054 MB/s

        Random Read 512KB :  101.938 MB/s

        Random Write 512KB :    47.170 MB/s

    Random Read 4KB (QD=1) :    6.622 MB/s [  1616.7 IOPS]

  Random Write 4KB (QD=1) :    5.333 MB/s [  1302.1 IOPS]

  Random Read 4KB (QD=32) :  112.695 MB/s [ 27513.4 IOPS]

  Random Write 4KB (QD=32) :    27.577 MB/s [  6732.7 IOPS]

 

  Test : 1000 MB [Y: 27.2% (4552.6/16766.6 GB)] (x1)

  Date : 2014/06/01 13:44:23

    OS : Windows 8.1  [6.3 Build 9600] (x64)

 

Just to compare, here is mine on a larger system with all 3-4tb drives:

 

-----------------------------------------------------------------------

CrystalDiskMark 3.0.3 x64 © 2007-2013 hiyohiyo

                          Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 byte/s [sATA/300 = 300,000,000 byte/s]

 

          Sequential Read :    91.451 MB/s

          Sequential Write :    91.331 MB/s

        Random Read 512KB :    84.744 MB/s

        Random Write 512KB :    89.314 MB/s

    Random Read 4KB (QD=1) :    10.113 MB/s [  2468.9 IOPS]

  Random Write 4KB (QD=1) :    10.642 MB/s [  2598.2 IOPS]

  Random Read 4KB (QD=32) :    65.526 MB/s [ 15997.5 IOPS]

  Random Write 4KB (QD=32) :    92.553 MB/s [ 22596.1 IOPS]

 

  Test : 1000 MB [Z: 73.8% (30235.0/40985.0 GB)] (x1)

  Date : 2014/06/01 16:10:14

    OS : Windows 8.1  [6.3 Build 9600] (x64)

 

These don't have the reconstructive writes turned on because it doesn't seem to work in beta6, which is what I am running.  A friend is using it on 5.0.5 and getting consistently 100MB/s copying over SMB on real world copies.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...