Replacing drive by harddisk that's bigger than parity drive


BartDG

Recommended Posts

How fast a move can happen depends on whether it's on the same physical disk or not => if it's on the same physical disk it's nearly instantaneous, since it's just a function of changing directory information;  if it's allocated on a different disk, it has to be copied to the new disk and then deleted from the original one.

 

Link to comment
  • Replies 92
  • Created
  • Last Reply

Top Posters In This Topic

Ah, that makes sense!  Thanks Gary!

 

By now I've learnt the following:

 

- You can copy stuff to the cache disk when the mover is busy, but the speed becomes abysmal.  Better to let it finish first I guess.

 

- Using midnight commander in a terminal window instead of Windows explorer give me about 5MB/s speed gain.  That's not a whole lot, but hey, if the average speed is only about 20 MB/s, I'll take anything.  I've disabled the cache disk for now, because it didn't give me any gain since the stuff had to be moved by the mover afterwards anyway.

 

Why is copying from disk to disk so slow?  I know it's probably because of the parity calculations, but isn't this extremely slow?  Would this be the same speed "issue" I had with the parity-sync?  My CPU is a core2duo 8500, which should be fast enough I reckon?  What would be considered normal speeds for such an operation?  I like unRAID very, VERY much (and plan to stick with it because I like it so much), but this is about its biggest downside if you ask me.  As a server it's a thing of beauty, but when you start working on the server itself, it becomes incredibly slow.  Is there any way to speed this up somewhat?  (other CPU?  GPU it can take advantage of?  Some sort of co-processor maybe?).  Or is this just "the way it is?" :)

 

 

Link to comment

You are never going to get good speeds writing to a disk in an unRAID parity protected array (around 30-40MB/sec seems to be a typical maximum).  In unRAID each write operation actually involves 4 I/O operations.  The write process consists of reads of the parity disk and data disk to get the before state of the sector about to be updated (so that the change to parity can be derived) followed by write operations to the data disk and the parity disk of the updated sector.  There also needs to be a minimum of one disk rotation between the read and writes so latency can come into play as well, particularly with an array of disks with different rotational speeds.  Read operations just involve the data disk that is being used so are much faster.  This is why local write operations are often not much faster than doing it over the network as it is the disk speeds that are the limiting factor, not the network speed.  It is also the reason why using a cache disk speeds things up as then each write is just a single I/O operation.

 

Creating new files can also have significant overhead as depending on the allocation and split level strategy specified unRAID may have to examine several disks to determine which one should be used for any particular file.

 

There can also be hardware issues around the disk controller throughput and whether the cabling is good enough to run without retries getting triggered that can affect overall speeds achieved. 

 

Linux buffering can give a short term perceived improvement in performance as long as the amount of data  does not exceed the buffer space that Linux allows for disk I/O.  However ,ulti-meida files tend to be large and these are what unRAID is often used for so this buffer space can easily be exhausted.

Link to comment

Creating new files can also have significant overhead as depending on the allocation and split level strategy specified unRAID may have to examine several disks to determine which one should be used for any particular file.

 

Very good explanation, for me this part stopped being an issue with the move to xfs, it was painfully slow with reiserfs, sometimes taking like 30 seconds to begin writing, now is always instantaneous.

Link to comment

Diskspeed creates a file in the root of your flash disk with a nice graphical display of all speeds, diskspeed.html

The older version I've been using puts it in the currently selected directory, which is typically /root, which is in RAM disk, not on the flash drive. Perhaps BartDG should look there, though a reboot would delete it, of course.

 

I do remember a thread about people experiencing a big difference in speed between parity check and parity sync, but I think the symptoms were the opposite of what is being discussed here - the check was slower than the sync.

 

Link to comment

The older version I've been using puts it in the currently selected directory, which is typically /root, which is in RAM disk, not on the flash drive. Perhaps BartDG should look there, though a reboot would delete it, of course.

Indeed John!  I looked into /root, and there is was! :)  Cheers!

Link to comment

Ok, almost there!  I moved about all the stuff I wanted to move.  I now need to get rid of the "movies" share, but I can't find a way to do that.

 

A search reveals that others before me fixed that by telnetting into the server, running midnight commander, go to /mnt/user, and delete it from there.  That's what I did, it's effectively gone (also from /mnt/user0), but the "movies" share is still there when I look under the "shares" tab of the unRAID menu.  How can I get rid of it for good?

 

Thanks!!

Link to comment

Ok, almost there!  I moved about all the stuff I wanted to move.  I now need to get rid of the "movies" share, but I can't find a way to do that.

 

A search reveals that others before me fixed that by telnetting into the server, running midnight commander, go to /mnt/user, and delete it from there.  That's what I did, it's effectively gone (also from /mnt/user0), but the "movies" share is still there when I look under the "shares" tab of the unRAID menu.  How can I get rid of it for good?

It seems you cannot easily remove a share if the folder corresponding to it does not exists, or if it does exist and is not empty.  In your case use Midnight Commander to create the folder corresponding to the share on one of your disks.  Once you have done that you should be able to remove the share via the Shares tab.
Link to comment

I have a similar problem on my HP N54L when I mix Seagate ST4000DM000 & ST3000DM001 and HGST 4TB NAS drives on the built in controller.  When they are all Seagate I get 100+MB/s parity builds but when they are mixed with HGST it is 35-40MB/s.  I have two more drives (at 60 hour intervals) before I can see if HGST 4TB NAS only will up the speed to 100+MB/s.  I've traced it to one of the Seagates connecting at IDE speeds when the HGST drives are present.  The parity checks are all 100+MB/s.  I'm also going to check replacing the ST3000DM001 with a 3TB WD Red and see if that makes a difference.

Well I can now say I have a compatibility problem with HGST NAS 6TB drives and my HP N54L.  The N54L is now all HGST drives I still get 35-45MB/s drive rebuilds when the drive to rebuild in on the N54L HDD controller.  The N54L has the custom bios from "theBay" that enables the optical ports to run as AHCI so I could see a bios setting causing this.
Link to comment

I have a similar problem on my HP N54L when I mix Seagate ST4000DM000 & ST3000DM001 and HGST 4TB NAS drives on the built in controller.  When they are all Seagate I get 100+MB/s parity builds but when they are mixed with HGST it is 35-40MB/s.  I have two more drives (at 60 hour intervals) before I can see if HGST 4TB NAS only will up the speed to 100+MB/s.  I've traced it to one of the Seagates connecting at IDE speeds when the HGST drives are present.  The parity checks are all 100+MB/s.  I'm also going to check replacing the ST3000DM001 with a 3TB WD Red and see if that makes a difference.

Well I can now say I have a compatibility problem with HGST NAS 6TB drives and my HP N54L.  The N54L is now all HGST drives I still get 35-45MB/s drive rebuilds when the drive to rebuild in on the N54L HDD controller.  The N54L has the custom bios from "theBay" that enables the optical ports to run as AHCI so I could see a bios setting causing this.

 

That’s interesting, the OP uses an Intel chipset and appears to have the same speed issue, a while ago I also found a similar problem with V6 and  Samsung F3G disks, although in that case parity checks are also affected, after that post I confirmed that they work normally on V5.

Link to comment

I have a similar problem on my HP N54L when I mix Seagate ST4000DM000 & ST3000DM001 and HGST 4TB NAS drives on the built in controller.  When they are all Seagate I get 100+MB/s parity builds but when they are mixed with HGST it is 35-40MB/s.  I have two more drives (at 60 hour intervals) before I can see if HGST 4TB NAS only will up the speed to 100+MB/s.  I've traced it to one of the Seagates connecting at IDE speeds when the HGST drives are present.  The parity checks are all 100+MB/s.  I'm also going to check replacing the ST3000DM001 with a 3TB WD Red and see if that makes a difference.

Well I can now say I have a compatibility problem with HGST NAS 6TB drives and my HP N54L.  The N54L is now all HGST drives I still get 35-45MB/s drive rebuilds when the drive to rebuild in on the N54L HDD controller.  The N54L has the custom bios from "theBay" that enables the optical ports to run as AHCI so I could see a bios setting causing this.

 

That’s interesting, the OP uses an Intel chipset and appears to have the same speed issue, a while ago I also found a similar problem with V6 and  Samsung F3G disks, although in that case parity checks are also affected, after that post I confirmed that they work normally on V5.

If I find a bios solution I will post it.
Link to comment

The N54L is now all HGST drives I still get 35-45MB/s drive rebuilds when the drive to rebuild in on the N54L HDD controller.  The N54L has the custom bios from "theBay" that enables the optical ports to run as AHCI so I could see a bios setting causing this.

Ah, this is very interesting info! So it seems I'm also SOL just because I chose HGST drives?  I've just checked and my motherboard is using the most recent version of the BIOS already. And since that was one released in 2009, I think it's pretty safe to say no further updates should be expected...

 

But doesn't the N54L use an AMD Turion CPU (and thus an AMD chipset)?  If so, the problem isn't solely with Intel chipsets...

 

I doubt this problem will be fixable.  Maybe by using a separate PCIe card, but even then...  I might have a look at the hardware compatibility list.  I could give out the hardware of this server to my youngest, he's reaching the age where he could start using his first pc.  That would give me the opportunity to buy new hardware. :) 

 

Should I do this, and I create a new unRAID server with new hardware, but with the same harddisks, I'm guessing this will be the same as wel you choose "new config"? In other words: pay attention to how the drives are assigned, choose the correct one for parity etc, and then everything should be peachy?

Link to comment

Should I do this, and I create a new unRAID server with new hardware, but with the same harddisks, I'm guessing this will be the same as wel you choose "new config"? In other words: pay attention to how the drives are assigned, choose the correct one for parity etc, and then everything should be peachy?

 

You don’t have to do anything when changing hardware, Unraid recognizes the disks by serial number, just boot up and you should be ready to go.

Link to comment

The N54L is now all HGST drives I still get 35-45MB/s drive rebuilds when the drive to rebuild in on the N54L HDD controller.  The N54L has the custom bios from "theBay" that enables the optical ports to run as AHCI so I could see a bios setting causing this.

Ah, this is very interesting info! So it seems I'm also SOL just because I chose HGST drives?  I've just checked and my motherboard is using the most recent version of the BIOS already. And since that was one released in 2009, I think it's pretty safe to say no further updates should be expected...

 

But doesn't the N54L use an AMD Turion CPU (and thus an AMD chipset)?  If so, the problem isn't solely with Intel chipsets...

 

I doubt this problem will be fixable.  Maybe by using a separate PCIe card, but even then...  I might have a look at the hardware compatibility list.  I could give out the hardware of this server to my youngest, he's reaching the age where he could start using his first pc.  That would give me the opportunity to buy new hardware. :) 

 

Should I do this, and I create a new unRAID server with new hardware, but with the same harddisks, I'm guessing this will be the same as wel you choose "new config"? In other words: pay attention to how the drives are assigned, choose the correct one for parity etc, and then everything should be peachy?

I'm thinking my problem might be a bios change needed.  Will find out in a day or two.  Whenever the rebuild finishes.  Actually will be after the following check which is still a day away before I can start it.
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.