unRAID Server release 4.5-beta6 available


Recommended Posts

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

After reading this, I thought I would try it myself.  If I write to \\tower\movies (using cache) I get 18-20MB/s.  If I write the same file to \\tower\cache\movies, I get 55-60MB/s.

 

 

Link to comment
  • Replies 314
  • Created
  • Last Reply

Top Posters In This Topic

In testing out 'cache_dirs' by Joe I've found a few strange behaviors in spinning drives up/down.

 

If some drives are spun up and I click [spin Down], then the remaining drives are spun up first, and then all are spun down except the parity drive. Re-clicking [spin Down] has no effect after that.

 

If I click [spin Up] first and then click [spin Down] it seems to work correctly.

 

Link to comment

Upgraded from 4.4.2, no issues.  :)

 

Just running basic with 3x1TB drives. P45 board and Intel Celeron 430 single core chip.  No speed increase on parity check, but I did not have speed issues previously.  The lm_sensors package that is included, will it be making it's way into the webUI in later releases?

 

Link to comment

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

After reading this, I thought I would try it myself.  If I write to \\tower\movies (using cache) I get 18-20MB/s.  If I write the same file to \\tower\cache\movies, I get 55-60MB/s.

 

 

 

I sent you a PM

Link to comment

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

After reading this, I thought I would try it myself.  If I write to \\tower\movies (using cache) I get 18-20MB/s.  If I write the same file to \\tower\cache\movies, I get 55-60MB/s.

 

 

 

I sent you a PM

 

I'm noticing the same issues with cache writing etc. I also found I have some duplicate problems when I opened my syslog... going to have to fix that lol. Any insight on the caching would be helpful though since I definitely have seen a performance decrease recently.

Link to comment

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

After reading this, I thought I would try it myself.  If I write to \\tower\movies (using cache) I get 18-20MB/s.  If I write the same file to \\tower\cache\movies, I get 55-60MB/s.

 

 

 

I realize I had backups of 4.4.2 on my flash drive, so I renamed the files and rebooted.  I get 46-50 MB/s to \\tower\movies and 55-60 MB/s to \\tower\cache\movies.  So, something has definitely changed.

Link to comment
Actually' date=' no.  The files you are referring to are called '.reiserfs_priv' and they exist only in the root directory of a file system.  They are used to store "extended attributes" which are necessary to support Active Directory correctly.  All releases prior to 4.5-beta2 should never create these files.[/quote']

I'm running 4.4.2 on my main box and never went higher yet I have the .reiserfs_priv files....

 

???

 

Link to comment

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

After reading this, I thought I would try it myself.  If I write to \\tower\movies (using cache) I get 18-20MB/s.  If I write the same file to \\tower\cache\movies, I get 55-60MB/s.

 

 

 

I realize I had backups of 4.4.2 on my flash drive, so I renamed the files and rebooted.  I get 46-50 MB/s to \\tower\movies and 55-60 MB/s to \\tower\cache\movies.  So, something has definitely changed.

 

 

What did you have backup files of?  I have been having some very slow copy speeds to cache (15-20 MB/sec).  I don't believe I have any old unraid files on my flash drive. 

Link to comment

I am having trouble accessing my unRAID after upgrading from 4.5-beta4 to 4.5-beta6. I mapped to the flash and copied the bzimage and bzroot files overwriting the old. I then rebooted but after a few minutes I could not access tower. I tried to ping the assigned static ip and did not receive a reply. I power cycled the box and still nothing. I don't have a monitor keyboard or mouse connected as I set the bios to bypass any errors for that. I did pull the flash and and booted another system with it or at least to the point where I could choose unRAID or memtest.  ???

 

Edit: Received repaired board back from MSI and all is working well.  :)

Link to comment

Greetings, I'm a new unRAID user and am happily running a PRO version of 4.5b6.  I'm very impressed with the solution unRAID provides and am very happy to be supporting Tom.  I've found almost everything I needed by scouring these forums... though admittedly with some difficulty.  I hope to contribute some lessons learned to the FAQ, though that's another story.

 

I think I have a bug report or two, depending upon how certain functionality is supposed to work.

 

I too have the magically disappearing and reappearing http:\\tower web interface, though I can always see the web interface at the IP address via http:\\192.168.1.101.  I wouldn't even care, except that the issue becomes evident when using uuMenu, which seems to automatically override the servername in the URL, replacing the IP address with the 'tower' servername when you click the various links in the menu.  The problem affects the core unRAID web menu as well, though at least it doesn't replace the IP with 'tower'.  It appears as if the http server is going deaf to the tower name, and interacting with the server (spinning up drives, etc) seems to remedy the situation for a while. 

 

I've seen others post on the non-responsive tower issue, though unlike some I can always network browse to \\tower\shares.  In fact, I can be browsing shares on \\tower while at the same time receiving 'server not found' for http:\\tower.  I'm using a static ip on the tower server, and the issue has occured on both Vista and XP clients.

 

My second issue is with the new Fill-up Share Allocation Method, combined with the Minimum Free Space.  I specified 45GB of min. free space (45000000) on the share, and I expected this to apply to every drive individually.  As I copied Blu-Ray ISOs into the array and filled up the first drive, it correctly rolled over to the second drive when there was 33GB left for the next file.  I continued to fill up the second drive, and finished my ISO copying tasks with 18GB free.  I then ripped a Blu-Ray ISO straight to the array.  I expected it to go to the third drive, since the second drive now had less than the specified 45GB free, yet unRAID proceeded to fill-up the second drive to the brim, leaving 0 bytes available, didn't roll to the third drive during the rip, and the rip error'ed out. 

 

Perhaps I'm misunderstanding what the fill-up and min space free parameters do.  With 33GB free on drive 1, and 18GB free on drive 2, I had 51GB free total, in excess of the configured 45GB minimum.  But if that's how it is supposed to work, that makes no sense to me, but fill-up definitely lived up to its namesake.

 

Let me know if I wasn't clear on any items or need to post syslogs or config data.  I can also recreate the test as needed.

Link to comment

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

I just made a thread about this problem in the 4.4 forum here http://lime-technology.com/forum/index.php?topic=3777.msg33082#msg33082 .

Link to comment

My second issue is with the new Fill-up Share Allocation Method, combined with the Minimum Free Space.  I specified 45GB of min. free space (45000000) on the share, and I expected this to apply to every drive individually.  As I copied Blu-Ray ISOs into the array and filled up the first drive, it correctly rolled over to the second drive when there was 33GB left for the next file.  I continued to fill up the second drive, and finished my ISO copying tasks with 18GB free.  I then ripped a Blu-Ray ISO straight to the array.  I expected it to go to the third drive, since the second drive now had less than the specified 45GB free, yet unRAID proceeded to fill-up the second drive to the brim, leaving 0 bytes available, didn't roll to the third drive during the rip, and the rip error'ed out. 

 

The reason for this has to do with which program is writing the file on the array.  If you 'copy' a file using Windows Explorer, it will create a file on the target (ie, the server) the same size as the original file, and then move the data over.  If you are using a program that creates the file 'on-the-fly', typically it will first create some nominal size small file, then as it proceeds, it 'grows' the file by appending new data to it.  Your 'ripper' apparently does the latter.  This is the reason 'fill up' was not included originally - but I added it due to customer request who understood the pitfall - guess I should document this :)

Link to comment

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

After reading this, I thought I would try it myself.  If I write to \\tower\movies (using cache) I get 18-20MB/s.  If I write the same file to \\tower\cache\movies, I get 55-60MB/s.

 

 

 

I realize I had backups of 4.4.2 on my flash drive, so I renamed the files and rebooted.  I get 46-50 MB/s to \\tower\movies and 55-60 MB/s to \\tower\cache\movies.  So, something has definitely changed.

 

Please try this experiment & let me know the result.  In 4.5-betaX there is a config parameter on the Settings page, under 'Disk settings' called 'Force NCQ disabled'.  Please set this to 'No' and let me know if there is any difference in cache write speed.

Link to comment

My second issue is with the new Fill-up Share Allocation Method, combined with the Minimum Free Space.  I specified 45GB of min. free space (45000000) on the share, and I expected this to apply to every drive individually.  As I copied Blu-Ray ISOs into the array and filled up the first drive, it correctly rolled over to the second drive when there was 33GB left for the next file.  I continued to fill up the second drive, and finished my ISO copying tasks with 18GB free.  I then ripped a Blu-Ray ISO straight to the array.  I expected it to go to the third drive, since the second drive now had less than the specified 45GB free, yet unRAID proceeded to fill-up the second drive to the brim, leaving 0 bytes available, didn't roll to the third drive during the rip, and the rip error'ed out. 

 

The reason for this has to do with which program is writing the file on the array.  If you 'copy' a file using Windows Explorer, it will create a file on the target (ie, the server) the same size as the original file, and then move the data over.  If you are using a program that creates the file 'on-the-fly', typically it will first create some nominal size small file, then as it proceeds, it 'grows' the file by appending new data to it.  Your 'ripper' apparently does the latter.  This is the reason 'fill up' was not included originally - but I added it due to customer request who understood the pitfall - guess I should document this :)

 

Thanks for responding.  Your absolutely correct about the ripper starting with a small seed file and growing it as the data is read from the disc.  I guess what is non-obvious to me is what the min free space parameter controls.  My expectation (just a guess, really) was that all new files, regardless of size, would be written to the next drive in the share after the current drive no longer met the min free space value.

 

Now (taking a wild guess here), if the min free space is divvied up among the current drives in use for that share, then I could have simply modified my min free space value ahead of time to account for it.  For example, since I wanted at least 45GB free on the 2nd drive, and there was 33GB left free on the first, I could have changed the min free value to 78GB.  And when the share grows to the third drive, I could add the first drive's free space (33GB) to the second drive's free space (17GB) plus 45GB, for a new min free space value of 95GB.

 

Of course, since I don't really know what min free space is doing behind the scenes, a little bit of documentation would be nice.  Thanks again!

Link to comment

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

After reading this, I thought I would try it myself.  If I write to \\tower\movies (using cache) I get 18-20MB/s.  If I write the same file to \\tower\cache\movies, I get 55-60MB/s.

 

 

 

I realize I had backups of 4.4.2 on my flash drive, so I renamed the files and rebooted.  I get 46-50 MB/s to \\tower\movies and 55-60 MB/s to \\tower\cache\movies.  So, something has definitely changed.

 

Please try this experiment & let me know the result.  In 4.5-betaX there is a config parameter on the Settings page, under 'Disk settings' called 'Force NCQ disabled'.  Please set this to 'No' and let me know if there is any difference in cache write speed.

 

Unfortunately, that did not help.  I changed it to "No", rebooted and tried it...still about 20MB/s. 

Link to comment

Thanks for responding.  Your absolutely correct about the ripper starting with a small seed file and growing it as the data is read from the disc.  I guess what is non-obvious to me is what the min free space parameter controls.  My expectation (just a guess, really) was that all new files, regardless of size, would be written to the next drive in the share after the current drive no longer met the min free space value.

That is exactly correct.  At the time a new object (file or directory) is created, the user share logic determines which disk of the share the new object should be created on.  Once an object has been created on a disk, it stays on that disk.  So an existing file can not be made larger than the amount of free space which is on the disk it's created on.  That's really the  purpose of the 'Min free space' setting: to allow room for existing files to grow on a disk.

 

Now (taking a wild guess here), if the min free space is divvied up among the current drives in use for that share, then I could have simply modified my min free space value ahead of time to account for it.  For example, since I wanted at least 45GB free on the 2nd drive, and there was 33GB left free on the first, I could have changed the min free value to 78GB.  And when the share grows to the third drive, I could add the first drive's free space (33GB) to the second drive's free space (17GB) plus 45GB, for a new min free space value of 95GB.

No divvying is taking place :)  The 'Min free space' refers to an absolute value which applies to each disk in the share.

 

Of course, since I don't really know what min free space is doing behind the scenes, a little bit of documentation would be nice.  Thanks again!

 

If you are writing data to the share using a program that incrementally grows files as it proceeds, then 'Fill up' is not really appropriate for this purpose unless you are using a Cache drive.  In this case your ripper will create one large file on the cache disk, and then when the Mover fires up, the final file size is known and it will behave the way you expect.  If you're not using a Cache drive, then

for what you're doing, you are better off using 'Highwater' allocation.  Make sense?

 

 

Link to comment

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

After reading this, I thought I would try it myself.  If I write to \\tower\movies (using cache) I get 18-20MB/s.  If I write the same file to \\tower\cache\movies, I get 55-60MB/s.

 

 

 

I realize I had backups of 4.4.2 on my flash drive, so I renamed the files and rebooted.  I get 46-50 MB/s to \\tower\movies and 55-60 MB/s to \\tower\cache\movies.  So, something has definitely changed.

 

Please try this experiment & let me know the result.  In 4.5-betaX there is a config parameter on the Settings page, under 'Disk settings' called 'Force NCQ disabled'.  Please set this to 'No' and let me know if there is any difference in cache write speed.

 

Unfortunately, that did not help.  I changed it to "No", rebooted and tried it...still about 20MB/s. 

 

Ok, thanks - it's either the linux kernel or new Samba release causing the slowdown... I'll figure out which it is and try to get a fix in for next release.

Link to comment

Not sure if this is related to the above posts but I'm sure my write speeds are slower since moving to the 4.5betas...

 

I used to be able to write at a max of about 20MB/s across my gigabit network from my laptop on 4.4. Since moving to the betas (staring at beta4 and now 6) I'm never getting more than 10MB/s. I've not changed anything that I can think of that would halve my speed.

 

If anyone has any suggestions on things to try to debug my speed that would be great.

 

Thanks,

 

Justin

Link to comment

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

   However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

 

After reading this, I thought I would try it myself.  If I write to \\tower\movies (using cache) I get 18-20MB/s.  If I write the same file to \\tower\cache\movies, I get 55-60MB/s.

 

 

 

I realize I had backups of 4.4.2 on my flash drive, so I renamed the files and rebooted.  I get 46-50 MB/s to \\tower\movies and 55-60 MB/s to \\tower\cache\movies.  So, something has definitely changed.

 

Please try this experiment & let me know the result.  In 4.5-betaX there is a config parameter on the Settings page, under 'Disk settings' called 'Force NCQ disabled'.  Please set this to 'No' and let me know if there is any difference in cache write speed.

 

Unfortunately, that did not help.  I changed it to "No", rebooted and tried it...still about 20MB/s. 

 

Ok, thanks - it's either the linux kernel or new Samba release causing the slowdown... I'll figure out which it is and try to get a fix in for next release.

 

Just to confirm this, it didn't solve the issue for me either. Thank you for taking care.

Link to comment

As a counterpoint data point, I have to say that the 4.5 betas have given me a huge boost in write speed.  This is writing to disk shares only, I do not use User Shares, which appear to be involved in all or most of the reports above.  My writes have always averaged about 9MB/s, but now have increased to almost 15MB/s, an enormous improvement!

 

The speed increase is so much better for me that, if Tom were to revert something back in order to restore the User Share writing speed, and that reversion also restored the previous slower speed on writes directly to disks, I would have to stick with the current version.  Hopefully, the problem is just with a module that is User Share related.

Link to comment

Thanks for responding.  Your absolutely correct about the ripper starting with a small seed file and growing it as the data is read from the disc.  I guess what is non-obvious to me is what the min free space parameter controls.  My expectation (just a guess, really) was that all new files, regardless of size, would be written to the next drive in the share after the current drive no longer met the min free space value.

That is exactly correct.  At the time a new object (file or directory) is created, the user share logic determines which disk of the share the new object should be created on.  Once an object has been created on a disk, it stays on that disk.  So an existing file can not be made larger than the amount of free space which is on the disk it's created on.  That's really the  purpose of the 'Min free space' setting: to allow room for existing files to grow on a disk.

 

 

Tom, thanks again, you've been so helpful.  I must apologize, as I now realize the fill-up logic appears to be working perfectly.  It turns out I inadvertently caused the volume to fill up. 

 

Here's how:  During my initial copying, I had copied an empty movie folder to my Blu-Ray share.  At the time the folder was created there was plenty of space on the 2nd drive in the share, so the empty folder ended up on drive 2.  By the time I got around to ripping the movie into the folder, the 2nd drive was below the min file space threshold, yet unRAID attempted to ensure the integrity of the folder and keep it whole on a single drive, so the ripped ISO went to that folder on drive 2, filled the drive up and errored out.

 

I just tested this again, in an identical scenario, yet this time I created the folder right before the rip.  The folder was correctly created on the 3rd drive, and the rip is now going into that folder on the 3rd drive.  Perfect!  The best part is that this works even when using a program that grows the file as it is created, rather than allocating the entire file size up front.

 

The lesson learned, when using Fill-up and Free Min Space, is don't create your movie folder until right before you rip it, otherwise the folder may end up on a drive with not enough free space by the time you do rip or copy data into it.  Copying movie folders worked correctly, not because the file space was pre-allocated, but because each destination folder doesn't get created until right before its contents get copied.

Link to comment

As a counterpoint data point, I have to say that the 4.5 betas have given me a huge boost in write speed.  This is writing to disk shares only, I do not use User Shares, which appear to be involved in all or most of the reports above.  My writes have always averaged about 9MB/s, but now have increased to almost 15MB/s, an enormous improvement!

 

The speed increase is so much better for me that, if Tom were to revert something back in order to restore the User Share writing speed, and that reversion also restored the previous slower speed on writes directly to disks, I would have to stick with the current version.  Hopefully, the problem is just with a module that is User Share related.

 

Interesting Rob - I'll run some tests writing to disk shares this evening and see how it compares....

Link to comment
Guest
This topic is now closed to further replies.