I'll wager its mostly due to not needing to resize and re-parity one drive.

On 20/03/14 10:58, Jeff Allison wrote:
I failed the suspect disk out of the array and now the rebuild is
16000K/sec 4x faster.

Strange.

Time to do some disk testing...

On 19 March 2014 14:59, Jeff Allison <jeff.alli...@allygray.2y.net> wrote:
I ran hdparm...

[root@nas ~]# hdparm -tT /dev/sdd <-- dud disk

/dev/sdd:
  Timing cached reads:   2318 MB in  2.00 seconds = 1158.86 MB/sec
  Timing buffered disk reads:   2 MB in 25.35 seconds =  80.79 kB/sec

[root@nas ~]# hdparm -tT /dev/sdc <-- good disk

/dev/sdc:
  Timing cached reads:   2470 MB in  2.00 seconds = 1234.85 MB/sec
  Timing buffered disk reads: 296 MB in  3.01 seconds =  98.35 MB/sec

Not much in it.

On 19 March 2014 14:23, Jeff Allison <jeff.alli...@allygray.2y.net> wrote:
The disk sector sizes are the same on all the disks.

Logical  Sector size:                   512 bytes
Physical Sector size:                  4096 bytes

Is chunk size stripe size?

[root@nas ~]# mdadm --detail /dev/md0
/dev/md0:
         Version : 1.2
   Creation Time : Fri Feb 21 09:33:55 2014
      Raid Level : raid5
      Array Size : 3905985536 (3725.04 GiB 3999.73 GB)
   Used Dev Size : 1952992768 (1862.52 GiB 1999.86 GB)
    Raid Devices : 4
   Total Devices : 4
     Persistence : Superblock is persistent

     Update Time : Wed Mar 19 14:22:35 2014
           State : clean, reshaping
  Active Devices : 4
Working Devices : 4
  Failed Devices : 0
   Spare Devices : 0

          Layout : left-symmetric
      Chunk Size : 512K

  Reshape Status : 28% complete
   Delta Devices : 1, (3->4)

            Name : nas.allygray.2y.net:0  (local to host nas.allygray.2y.net)
            UUID : 1a122cbe:ada65085:680e451c:180c7689
          Events : 21723

     Number   Major   Minor   RaidDevice State
        0       8       17        0      active sync   /dev/sdb1
        1       8       33        1      active sync   /dev/sdc1
        3       8        1        2      active sync   /dev/sda1
        4       8       49        3      active sync   /dev/sdd1

When I created the partitions I used the -a optimal which I thought sorted that?

On 19 March 2014 14:11, Jake Anderson <ya...@vapourforge.com> wrote:
its probably *madly* seeking which is why its so slow.
I wonder, what is the block size you are using on the disk and the stripe
size of your array?

If you are read modify writing a 4K disk in 512k blocks it'll be dog slow.

On 19/03/14 14:00, Jeff Allison wrote:
The thing I find strange is that in iostat the disk shows as 100% at 3/4
MB/s.

I wonder how iostat decides on the percent?

On 19 March 2014 10:53, Jake Anderson <ya...@vapourforge.com> wrote:
This isn't going to be an issue with sata vs whatever (though I do
suggest
running in ahci mode if thats an option)

The issue is probably going to be how mdadm is growing the array, it will
need to do a buttload of disk access to do that reading and writing every
sector on every disk and trying to keep everything in a consistent state
while doing so.

I don't know if it applies to whatever raid level you are using but is
there
something like an --assume-clean option you can pass it?
I'd also suggest asking in the mdadm list or perhaps IRC.
http://forums.whirlpool.net.au/archive/1056831 might be of interest.


On 18/03/14 20:02, Rachel Polanskis wrote:
On 18 Mar 2014, at 6:46 pm, Jeff Allison <jeff.alli...@allygray.2y.net>
wrote:

That's installed unfortunately didn't fix my problem. How badly
configured
does a disk need to be to only run at 4mb



Sorry for the suck eggs question, but you did enable all the features in
the BIOS e.g. turning on SATA II 3gbps support,
write cache disable etc?   In the URL link to the forum below they
discuss
all the optimum settings.  I am using
WD RED NAS drives (2x2tb) and Seagate 3Tb drives (latest model) in my
system so similar to yours....

rachel



On 18/03/2014 3:43 PM, "Rachel Polanskis" <gr...@exemail.com.au> wrote:
On 18 Mar 2014, at 3:14 pm, Jeff Allison <jeff.alli...@allygray.2y.net>
wrote:

Is it the O41072911.ROM?

Did you use flashrom of the dos disk thingo.

On 18 March 2014 14:06, gr0ve <gr...@exemail.com.au> wrote:
Seriously, you should flash the BIOS!  I get 80mbps reads on ZFS
and depending, 30-40mbps on writes.  Without the BIOS mod, you
are getting only IDE speeds there.  The original BIOS holds this
machine
back and it is perfectly safe.  The BIOS ensures AHCI support is
operational
as well as the 3gbps SATA II bus. Once you see the improvement, you
can choose to also select write cache enabled|disabled although
this is best with a UPS ;)


rachel
Hi,
The HP BIOS version is the O41072911.ROM as you suggest.
You need this to install the "theBay" ROM as well.

The process is shown online, but in short you copy the HP BIOS using a
DOS/windows installer to a USB stick then copy the "theBay" rom image
over
the
top. You could try to "dd" the image but it does some weird trickery to
make
the stick bootable for installing the BIOS.

You can look for TheBay_Microserver_Bios_041.rar online.
The source information is:



http://www.avforums.com/threads/hp-n36l-n40l-n54l-microserver-updated-ahci-bios-support.1521657/

And it has all the guff on getting the BIOS onto your N54L and also tips
on how to configure it.
I have all the files if you need them....

Once again, these are terrific little servers.  It has an internal USB
port so I just loaded FreeNAS
onto an 8Gb USB stick and boot from there.  All the internal SATA disks
are in ZFS disk pools which
do my bidding. As I use ZFS, I went with 8gb ECC memory. I also added an
additional Gigabit Ethernet adaptor as the built in broadcom is general
networking and I run the second Gig-E port with Jumbo Frames using a
gigabit
crossover (there is such a thing)
to a Mac Mini with the thunderbolt port running Gig-E and doing iSCSI!
The Mac Mini runs esxi 5.5 and
all the data stores (running various species of Linux) hosted off the
HP-N54L.  It is like a little tiny
SAN, small but perfectly formed....


rachel

--
Rachel Polanskis                 Kingswood, Greater Western Sydney,
Australia
gr...@exemail.com.au             IT consulting, security, programming
           The more an answer costs, the more respect it carries.






--
Rachel Polanskis                 Kingswood, Greater Western Sydney,
Australia
gr...@exemail.com.au             IT consulting, security, programming
          The more an answer costs, the more respect it carries.



--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to