unRAID Server Release 5.0-rc12 Available


Recommended Posts

Hey Jowi from this

 

"Guess what. I've installed SimpleFeatures again (1.0.5) and the parity speed goes down to about 90 - 100MB/s... if you actually watch it IN simplefeatures gui.

Once you close the simplefeatures webpage, and go back to unmenu, you will see the parity speed increase to 150MB/s again...

Using the latest SimpleFeatures (1.0.11) is even worse, it basically stops the parity check with speeds from 20-30MB/s, which is unworkable."

 

When you did the last test with latest Simplefeatures did speeds go back up to full speed when you checked via unmenu??  ie is it only present when looking via the simple features web interface??

 

What hardware do you use to get those speeds? Can you specify please? I get over 100 MB/s only at the start of a parity check and it lowly drops to 70-80 MB/s towards the end.

Link to comment
  • Replies 480
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Pardon me, but if you will hold people to this then you must hold people to staying on topic.  Noone wants to read the RC thread if there are a lot of posts that have nothing to do with the RC. 

 

That is the case here.  it is getting old.  Noone should have to read through this extraneous stuff in order to get the critical information. 

 

Sorry to barge in like this. Have been reading many threads regarding RCs. This time I didn't however. I am now on RC11. Is there any benefit in upgrading to RC12 or RC12a? What is changed from RC11 to RC12 and from RC12 to RC12a? As I am on a X9SCM-F mainboard, is the slow write issue solved? Are parity checks up to speed again like in Beta12a?

 

As a general rule of thumb if you decided to join a testing cycle you should keep up to date with latest unless there is a specific reason you cannot.

 

This is not an unRAID thing but a general tester thing.

Link to comment

What hardware do you use to get those speeds? Can you specify please? I get over 100 MB/s only at the start of a parity check and it lowly drops to 70-80 MB/s towards the end.

See signature. If you are using SF, try closing SF in your browser and watch the speed in unmenu.

Link to comment

So far 12a works fine for me (was at rc10 earlier).  I am getting the same problems with a SF (1.0.11) window open.  My speeds drop from around 65MB/s to 20MB/s within the span of 15 seconds. 

Then when I close the SF window, the parity check goes back up to 65MB/s in about 30 seconds.

 

My speeds are slow because I'm using two older 500GB Hitachi drives on a PCIe1x Sil3132 (getting a new controller to replace).  Once I get past 500GB in the parity check, my speeds climb.  I'll check SF again when I'm past 750GB (my third slowest drive).

Link to comment

From reading other posts, I see that a problem has been identified in SF that will badly degrade parity syncing if the SF GUI is open.  If you do not have the SF GUI open the speed is normal.  It is something to do with the way that SF is trying to detect disk temperatures, so you should also not install the SF temp plugin.  Hopefully we will shortly have an updated version of SF that resolves this issue.

Link to comment

No connectivity to the network (rollback to 4.7)

NIC: Realtek RTL8102EL

 

Have you tried any other beta/RC?

 

Yes I have: RC10, RC11, & RC12a all the same. 4.7 is the only one with network connectivity when doing an ifconfig.

 

EDIT:

ok now I am on RC5 with network connectivity.

 

rc5-r8168 did not work

rc6-r8168-test did not work

rc6-r8168-test2 did not work

rc7 did not work

 

So i do not know what changed with the implemented drivers since RC5

Link to comment

I don't think rolling back is the right answer.  If you want a stable system, go back to the last final veresion, 4.7.  Otherwise, keep up with the current RC and report all errors.  If you don't work with Tom and company to resolve the issues that you have, you won't be happy with v5 Final because it may not contain fixes you need.

 

This thread is getting long.  It would be nice to have a current list of reported issues and confirm the status of those issues (for example, Tom's knows and is working on it).  I think the list of actual issues is short. 

 

Some people are reporting NFS file / share issues.

Some say we have issue with parity speeds, related to SF if gui is open.

 

What else is keeping this rc from going Final?

 

My only issue right now is that I lost my temp readings, which is a SF issue.

Link to comment

I don't think rolling back is the right answer.  If you want a stable system, go back to the last final veresion, 4.7.  Otherwise, keep up with the current RC and report all errors.  If you don't work with Tom and company to resolve the issues that you have, you won't be happy with v5 Final because it may not contain fixes you need.

 

Excuse me, but I've run almost every V5 issued since beta3, on my one and only (live) system.  I believe that I have done my part in identifying, and helping to resolve, several issues along the way.  I have developed, and made available, at least two V5 plugins.  I have run both rc11 and rc12, but cannot accept having to reboot my desktop machine every time I manipulate a matroska file (something I tend to do several times a day), in order to regain access to my Movies share.  Apart from this issue with stale nfs file handles I have no problem with either rc11 or rc12.  I loaded rc12, knowing that the stale handle issue was not fixed, simply in order to exercise it on my hardware, for the benefit of the community, and to my inconvenience.

 

I have reverted to rc10 because, for me, it is stable with just two minor annoyances which I can live with.  One of these does appear to be resolved in rc11/12, the other is a much milder form of the stale file handle issue (I'm still struggling to understand how most of the stale file handle problems were resolved in rc4, but returned in rc11).  However, Tom acknowledges the problem with stale file handles, appears to understand the cause and has a proposed resolution (although it seems that this will not be implemented until after V5.0 final) - I see little point in my continuing to persist with this.

 

Having been running V5 for more than two years now, I have no inclination, desire or motivation to return to V4 - thank you very much.

 

I believe that you, yourself, declined to install rc12, so I would ask you to keep your hypocritical advice to yourself!

Link to comment

good God, take it ez.  Didn't mean to ruffle your feathers.  I just want to encourage poeple to use the current RC, if possible.  In your case, Tom has already said he was working the issue, so makes sense for you to roll back until this is sorted out. 

 

Yes, I skipped rc12 because it had already been identified not to work with my nic, so no need.  As soon as 12a came out that fixed the nic issue, I upgraded.  To be honest, if I hadn't seen that the nic driver issue came up, I would have went to 12 and would of had to go back.

 

I understand your position, at least now I do.  Makes sense to roll back until the nfs issue is fixed.  I don't use nfs, so that's why I don't have any issues.

 

And thanks for developing plugins.  I didn't know you did that either.  Which ones?

Link to comment

Quick update,

 

I deleted all the extended attributes that were on my unRAID share, via a Mac. As I was unable to find the any command via unRAID (to display the extend attribute yes to delete them NO via unRAID, should be available maybe next release...).

 

I then deleted the AFP DB (even thought there was nothing wrong with it, but wanted to start out completely fresh) as well as all the apple files/dir's on the array.

 

Re-enabled AFP and let the DB generate itself as well as the Apple files. Since I am using a cache drive they were placed there, upon executing mover. ALL moved successfully now. No more mover/rsync crashing. Mover/rsync not crashing = no loss of 'user0' and no kernel crashes upon stopping array and/or shutting down.

 

So what I have learned is a corrupt extended attribute will cause mover/rsync to crash there by losing 'user0' and a several other issues afterwards.

 

Looking at how many extended attributes I have now versus how many I had before I deleted them all to start fresh is a totally different count. I cant figure out what corrupted them. It could have been from previous kernel crashes stemming from bad 5.0 Betas and RC's and/or moving data around in the array. Since I was unaware and thus did not monitor when/how many/etc. entailing extended attributes. But I figure I should have had as many extended attributes re-generate for a lack of better word as I had see before starting all over. Some shares no longer have any when they previously had several. Those which do have, have less then previously. I am not sure about all this, as I my understanding is an extend attribute is just that, additional metadata to an existing file or directory. So when I deleted them, they should have never come back, right? But some did... while others didn't. So does that mean that when I moved data from one disk to another in the array, somehow they were left behind. That should not be the case as they are tied to the particular file/directory. Or I got this all wrong. But since there is no doc's for all this, very grey area at the moment or at least of me.

 

Which brings up, what can successfully copy and/or move data and its extended attributes around successfully.

 

Does unRAID's MC (midnight commander) support extended attributes by default, if that is used to move data around the unRAID array? what version of MC does unRAID use?

Does Windows Explorer's cut/paste support extended attributes by default, if that is used to move data around the unRAID array?

Does OS X support extended attributes by default, if that is used to move data around the unRAID array?

 

So the big issue for me has been resolved and explains why I have had issues with mover/rsync for quite sometime.

 

Tom did not state in the release notes when 'X' was added to support extended attributes for mover's rsync code. AFP and extended attribute support have had changes and fixes through several releases so at some point these combinations went sour for my config it seems. I say this because I must have had data with extended attributes but unRAID (or the method of moving data I used) failed to properly move that data with extend attributes, or possible unRAID crashing in several releases I upgrade to and caused these extended attributes to become corrupted or maybe rolling back on some release, who knows... Once mover logic had the 'X' addition added to it, is when the mover crashes showed them self and was not able to resolve them until now (finally).

 

I understand not everyone uses files with extended attributes (or may not know they do). But a heads up that this can become a problem at any point in time should the issue stem from how we move data around on unRAID that doesn't support extend attributes.

 

So over all this release is good (running for 3 days now since fixing). Will be testing parity check soon. Speeds are hard for me to gauge as I have some old drives in the array and am not aware of an approved method for testing speeds (disk to disk, network to disk). I am happy with the speeds from network to the cache disk is all I know, they have change a bit from the releases but I guess are in range. RC12a was the fastest but I don't foresee unRAID getting back to those days.

 

For outstanding I have:

Mover should not wake up disk#1 when either there is no data to move at all or no data slated for that disk.

We used to be able to see duplicates in syslog, that has been removed and the indexer is not practical for finding duplicates.

A plugin manager was slated for 5.0, havent seen any movement or concrete statement if it is on the chopping block for 5.0

A new alias 'user' has been introduced with RC12/a, would be appreciated that some explanation and/or, documentation/sample around it.

 

I don't use NFS, but clearly from the posts there are transport disconnect issues that still plague those who use NFS.

 

I also experience brief glitches when watching say a movie. My disks are set to spin down every 30 mins and when watching a movie that is 2 hours long I see it glitch/pause for about 1-2 seconds every half-hour, pointing me to unRAID  attempting to spin down the drive. I have not had this in the past, I would like to say starting around RC10 if I am not mistaken.

 

Link to comment

good God, take it ez.  Didn't mean to ruffle your feathers.

 

Okay - sorry if I came on a bit heavy!  I was writing that at 1am, after a long day!  I think it was the advice to downgrade to 4.7 which upset me.  IIRC, I have never run 4.7, having jumped on to V5 betas quite early.

 

I just want to encourage poeple to use the current RC, if possible.

 

Indeed, and, in general, I agree with you.

 

In your case, Tom has already said he was working the issue, so makes sense for you to roll back until this is sorted out. 

 

Yes, I skipped rc12 because it had already been identified not to work with my nic, so no need.  As soon as 12a came out that fixed the nic issue, I upgraded.  To be honest, if I hadn't seen that the nic driver issue came up, I would have went to 12 and would of had to go back.

 

I understand your position, at least now I do.  Makes sense to roll back until the nfs issue is fixed.  I don't use nfs, so that's why I don't have any issues.

 

Okay, thanks!

 

And thanks for developing plugins.  I didn't know you did that either.  Which ones?

 

I have created dovecot (mail server) and mpop (mail fetcher) plugins so that all my mail is handled, filtered and spam-trapped on my unRAID server, and can be read/written from any other m/c in the house.  I mainly use the Thunderbird client on Ubuntu, but have also used Android (tablet/phone) and RISC OS (a ROM-based OS for ARM machines) clients.

 

I am also in the process of converting Bagpuss' minidlna package to a plugin - I am using it, but haven't yet completed the web interface.

 

Okay, peace!

Link to comment

Looking into extended attributes a bit deeper. Searching the forums I found some having this problem at least as of 5.0Beta14, with each post displaying errors when  mover was run against "user.org.netatalk.supports-eas.%", research came up with "Default Extended Attributes backend".

 

Which now looks like to me that AFP is setting these EA's up as default. But why on some (AFP) shares and not others, I still cant tell. And no real standard.

What I mean by this is as followed. I have 2 mac clients, and both connect to unRAID AFP shares. Some share don't have these default EA's created on them and the ones that do have varies amounts. One share will have 3 default EA's, another only 2, another 5. So its not say based on setting a default EA per each AFP client connection.

 

You would also note that each value of the default EA's is the same across ALL EA's in any of the share's. Mine being "0seWVzAA" before I deleted them and after they were created once more after a new setup of AFP. So that would mean I could have repaired the 4 corrupted EA's possible by attempting to set their value, as we clearly see the value is the same for each of the default EA's that are generated.

 

So these EA's do not look like they stem from files we place on the array (user.org.netatalk.supports-eas.XXXXXX)

 

ex.

user.org.netatalk.supports-eas.1GU9Yz=0seWVzAA==

user.org.netatalk.supports-eas.9cfJ87=0seWVzAA==

user.org.netatalk.supports-eas.M9UYFC=0seWVzAA==

user.org.netatalk.supports-eas.QZBXPh=0seWVzAA==

user.org.netatalk.supports-eas.pyx2TW=0seWVzAA==

 

Reading the netatalk notes:

# ea                  -> none|auto|sys|ad

#                        Specify how Extended Attributes are stores. default

#                        is auto.

#                        auto: try "sys" (by setting an EA on the shared

#                              directory itself), fallback to "ad".  Requires

#                              writable volume for performing the test.

#                              Note: options:ro overwrites "auto" with "none."

#                        sys:  Use filesystem EAs

#                        ad:  Use files in AppleDouble directories

#                        none: No EA support

 

One could believe setting AFP shares in unRAID to readonly could possibly impact being able to set an EA on a share. But all my shares are public for quite sometime now (a loooong time again I may have change it to secure, in the 5.0 betas to test).

 

So now I am thinking maybe it does not have anything to do with us copying/moving our files around the array...

 

RC12

- shfs: return correct extended attribute value length

 

Beta11

- reiserfs: add patch that fixes a crash in reiserfs_delete_xattr during umount (http://www.spinics.net/lists/reiserfs-devel/msg02827.html)

Could this have caused our corruptions to our default EA's way back here?

 

Beta10

- afp: always mount array/cache disks with extended attributes enabled

- shfs: implement persistent inode numbers (AFP fix)

 

- Also somewhere in these Beta/RC's Tom added the additional 'X' to the mover script for rsync (in order to support moving files and their extended attributes).

 

 

So the corrupted/damaged EA's may have occurred with the various changes (and/or crash) of unRAID (no blame) to correct and get extended attributes and AFP setup properly. So time will tell and I will be closely monitoring my unRAID server EA's as time goes by. I have started a spreadsheet to do this.

 

Link to comment

@Lappen, I will PM you later this evening, tide up at the moment.

PM me with where you are storing your apple db (location), so I can adjust the instructions for you.

I will get you squared away.

 

Maybe you can post the steps to the group on one of the other threads so anyone else who wants to do this won't have to PM you.

 

 

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