unRAID Server Release 5.0-beta8d Available

Beta 8c copied and started. 

Everything looks normal- after a minute or two.

What's the deal with the MOUNTING or RESIZING that seems to randomly show up on the MAIN screen at startup?  With Beta 8a, it affected only the Seagate drives, now it affects only my two Samsung F4s.  During the last RESTART, both F4s showed MOUNTING for at least a minute, after which, one had added 7000 reads, while the other, only 400.  The next RESTART has the first F4 RESIZING, with the second F4 MOUNTING.  No errors.  All green.  Shares work.  Temps show with the array stopped...but what IS it doing for that first minute or two

??

From the first page of this thread -- Mounting and Resizing info -- http://lime-technology.com/forum/index.php?topic=13866.msg131244#msg131244

I have updated from 5b7 to 5b8b, and quickly to 5b8c

It would appear that the mover is not shifting files from the cache drive, either automatically or manually. If I activate the mover manually, I can see that the cache drive is being read and one of the data disks is being written to. however the reported space free of the data drive is not reducing.

Looking through this post I note that the mover script has been altered? For information my shares which use the cache drive are set to most free allocation method with a split level of 10

Will there ever be a way to tell which exact file generates a sync error? This way we can just compare the file on the data disk with the source file. Sometimes it's hard to know if the data on a data disk is bad or if data on the parity disk is bad.

short answer.  No.

Longer answer, not likely... it could be any bit on any of your disks or any of your hardware that flipped a bit.  It might be part of a file, or empty space, or part of the file-system structure.  Parity is computed and checked ( I think ) in sets of blocks on a disk..  It can encompass multiple files, or none.

Why would something like this not be possible :

Sync error block 3982309

Disk 1 : Free space

Disk 2 : Free space

Disk 3 : MyMostValuedMovie.mkv

Disk 4 : LastPictureOf.jpg

Disk 5 : File-system area

In this case I need to check 2 files, and do a reiser check on disk 5

I'm not proficient in Linux but a quick google gave :

debugreiserfs -1 3982309 /dev/hda1

which in the example gives : 3982309 is free in ondisk bitmap

http://smartmontools.sourceforge.net/badblockhowto.html#reiserfs_ex

Now it's the weekend, and I've got some time, I thought I'd try and do the upgrade to 5.0-beta8c.

 

I usually start by testing updates, and indeed any customisations on a virtual machine that I have set up with tiny 8GB dummy drives. Because I'm using a Mac, it's not possible to actually use a USB disk for this, and in the past I've used an extra SATA dummy disk as the flash, which has worked fine. Obviously I'm only able to simulate the free version of unRAID like this, but that's fine for testing.

 

With 5.0-beta8c, I'm not able to do this because I'm getting the 'Segmentation fault' error that users of beta8a were having on the first page of this thread. I'm wondering if that's something that can be fixed early, as using a VM for development and testing is very valuable. I'm also thinking that this issue might exist if anyone is trying to use the free version with a real flash drive, though I'm not able to test this.

This is corrected in upcoming -beta8d.

Thanks Tom,

I've also noticed some other strange behavior that I'm hoping you can help with...

In order to allow me to have the maximum amount of drives in my case for the array, I'd installed a USB HDD for my add on applications (So far Plex and Squeezebox server). This also had some other beneficial side effects, because running these applications on the cache disk meant that they had to be stopped before the array could be stopped in the web UI. On a disk outside the array, they could run on their own, doing whatever they pleased without interfering.

Since the update to beta8c, I've been getting a lot of 'kernel Oops' when stopping the array, this doesn't happen if I take the USB disk out and run things from the cache drive.

To be honest, I had noticed these errors before, so it may not be a beta8c thing, though in this latest version it's much more repeatable (happens every time I stop the array if I've ever started any processes on the USB HDD).

If it helps, the USB was mounted at /mnt/apps, shared over SMB by adding to the smb-extra file in /boot/config, and formatted with reiserfs.

There's a critical bug fix in this release having to do with data rebuild.  There is a corner case that comes up where, if during a data rebuild of a disabled disk (or disk replaced with a larger one), if a write-request occurs for another disk in the same stripe for the disk currently being rebuilt, it's possible the data for the disk being rebuilt is not actually written.  Later, this will cause a Parity Check 'sync error'.

 

This greatly worries me. I had my most crucial disk fail last week on b7. I rebuilt it with a bigger driver, and I did writes while doing so. What should I do, I haven't had any corrupt data that i've found but i'd like to make sure.

 

"Correct any Parity-Sync errors by writing the Parity disk with corrected parity." makes it seem like running parity would overwrite parity with disk data. Isn't this exactly what I wouldn't want to do? I believe the best solution in my case would be to run parity and have parity overwrite data on the data discs? If so, how can I do that?

 

I will run a parity sync in the mean time with the box uncheck, just to see if I have any errors.

If your parity check/nocorrect indicates parity errors, then you can disable the data disk you just resized, and then rebuild it.  This will correct those blocks on the resized disk, provided they are the cause the parity check errors.  To do this:

1. Stop array, unassign the resized disk.

2. Start array, that disk will now be disabled.

3. Stop array, re-assign the same disk.

4. Start array, now a data-rebuild will take place.

Probably if you want to do this, if possible instead of assigning the same disk, use another disk of same size to rebuild onto.  That way, if something goes wrong, you still have the original resized disk.

I've installed it... I can't get to the web interface.  I logged on to the server, and ran the emhttp command by hand and get a segmentation fault.

 

It is on the network, as I can telnet to it.

 

I have exactly the same problem. Restarted, but emhttp never came up. Telnet in and start it manually, and get segfault.

 

Attached syslog.

 

 

Having the same issue with 8c

 

try this here

This won't be effective - cause of this is a bug fixed in -beta8d.

Beta 8c copied and started. 

 

Everything looks normal- after a minute or two.

 

What's the deal with the MOUNTING or RESIZING that seems to randomly show up on the MAIN screen at startup?  With Beta 8a, it affected only the Seagate drives, now it affects only my two Samsung F4s.  During the last RESTART, both F4s showed MOUNTING for at least a minute, after which, one had added 7000 reads, while the other, only 400.  The next RESTART has the first F4 RESIZING, with the second F4 MOUNTING.  No errors.  All green.  Shares work.  Temps show with the array stopped...but what IS it doing for that first minute or two

 

??

 

The status of the data disks can be "Mounting", "Resizing", or show a numeric value, which would indicate disk is mounted.  The "Resizing" status is just code running to enlarge the file system, which will actually do nothing unless you replaced a smaller disk with a larger one.  These status messages used to be 'hidden' because, up until 3TB drives came along, for the most part, resizing was fast enough that no one complained of the browser hanging.  But enlarging a file system from say 1TB to 3TB takes a pretty long time, especially since resync is running as well, with the result of it appearing that the browser was hung.  So I "fixed" this in beta8, so at least you Refresh the page and watch the I/O counts change.  So what you see there is going to depend on timing, that is, your hardware config.  In your case, if you see numerous I/O on one of your disks, probably it's replaying transactions (did your server have an abnormal shutdown?).  This would also be evident in the system log.

From the first page of this thread -- Mounting and Resizing info -- http://lime-technology.com/forum/index.php?topic=13866.msg131244#msg131244

I thought I already explained this somewhere 

I have updated from 5b7 to 5b8b, and quickly to 5b8c

 

It would appear that the mover is not shifting files from the cache drive, either automatically or manually. If I activate the mover manually, I can see that the cache drive is being read and one of the data disks is being written to. however the reported space free of the data drive is not reducing.

That seems impossible.

Looking through this post I note that the mover script has been altered? For information my shares which use the cache drive are set to most free allocation method with a split level of 10

A couple things to check:

a) after mover runs, do you still see the same files on the cache drive?  Is there a copy of them on a data drive?

b) does the top level share name on the cache drive exist also on at least one data drive on the array?

Thanks Tom,

 

I've also noticed some other strange behavior that I'm hoping you can help with...

 

In order to allow me to have the maximum amount of drives in my case for the array, I'd installed a USB HDD for my add on applications (So far Plex and Squeezebox server). This also had some other beneficial side effects, because running these applications on the cache disk meant that they had to be stopped before the array could be stopped in the web UI. On a disk outside the array, they could run on their own, doing whatever they pleased without interfering.

 

Since the update to beta8c, I've been getting a lot of 'kernel Oops' when stopping the array, this doesn't happen if I take the USB disk out and run things from the cache drive.

 

To be honest, I had noticed these errors before, so it may not be a beta8c thing, though in this latest version it's much more repeatable (happens every time I stop the array if I've ever started any processes on the USB HDD).

 

If it helps, the USB was mounted at /mnt/apps, shared over SMB by adding to the smb-extra file in /boot/config, and formatted with reiserfs.

Please post system log resulting from oops.  This is possibly result of race condition between un-mounting last disk and stopping the unRaid driver, which has been fixed in -beta8d.

I don't have the system logs from this any more I'm afraid, I was kinda hoping that you would have some ideas, sorta like you did!

I actually think you might be right with your guess, because the errors that popped up on the console did include something about a /dev/sdx error every time.

Once beta8d is available, I'll move things back over to the USB and give it a go!

Thanks again!

As a suggestion for your javascript link disabling issue. Why not implement a javascript library to do this for you?

Essentially should be as easy as writing a simple function to replace all child a and input elements under body with their contents only, without surrounding tags.

Also, can we stop the _parent update.html javascript to stop greying out links? It should be called on certain user actions, not for everything (including just looking at syslog). It's confusing for users 

Cheers for all of your hard work, once more!

As a suggestion for your javascript link disabling issue. Why not implement a javascript library to do this for you?

 

Essentially should be as easy as writing a simple function to replace all child a and input elements under body with their contents only, without surrounding tags.

 

Also, can we stop the _parent update.html javascript to stop greying out links? It should be called on certain user actions, not for everything (including just looking at syslog). It's confusing for users 

 

Cheers for all of your hard work, once more!

Here's the current code:

function disable_form_elements() {
  for (var i=0; i<top.window.document.forms.length; i++) {
    var x = top.window.document.forms[i];
    for(var j=0; j<x.length; j++){
        x.elements[j].disabled = true;
    }
  }
}
function disable_links() {
  for (var i=0; i<top.window.document.links.length; i++) {
    var x = top.window.document.links[i];
    // no cross-browser way to disable link, so just turn it gray 
    x.style.color="gray";
  }
}
disable_form_elements();
disable_links();

Are you suggesting to search through document.body.innerHTML and basically remove the begin/end anchor tags?

http://radio.javaranch.com/pascarello/2005/05/17/1116355421179.html

I'll test this one myself in a number of browsers and fix any potential issues in modern browsers.

Yep. As far as I can see, each action that greys a link will finish with refreshing the page. It seems you don't need to keep the links in-tact.

However it could be relatively straight forward to keep tag information to rebuild the links without refreshing the page, if you really needed. Just replace the tag with <div class="replace.a/input">, and attach href information in the div for rebuild of the original tag. A function would be needed to go through each div class, and gather the information, then replace the div with its respective tag.

jquery does make this very easy...  

http://stackoverflow.com/questions/4625893/disable-and-re-enable-the-href-and-onclick-on-elements

I just replaced an "old" WD20EARS with an new WD 3TB drive. Bt the rebuild won't start for some reason. I always get the message:

Stopped. Upgrading disk.

And nothing happens.

I have tried beta7 and beta8c. No difference.

Is it not possible to replace a drive by a bigger one?

It would be nice if you could give me a hint.

Regards,

Chris

I just replaced an "old" WD20EARS with an new WD 3TB drive. Bt the rebuild won't start for some reason. I always get the message:

 

Stopped. Upgrading disk.

 

And nothing happens.

 

I have tried beta7 and beta8c. No difference.

 

Is it not possible to replace a drive by a bigger one?

 

It would be nice if you could give me a hint.

 

 

Regards,

 

Chris

 

... the thing is that the disc is not doing anything. The activity LED is off, and it looks like nothing happens.

I love this forum. People here are really interested in helping each other.

Thanks for that.

Chris

... the thing is that the disc is not doing anything. The activity LED is off, and it looks like nothing happens.

 

I love this forum. People here are really interested in helping each other.

 

Thanks for that.

 

Chris

... and I also can't find a process via 'ps -ef' that seems to work on the "UPGRADE_DISC" task.

I guess the problem has been described before:

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

But in the last post it is stated the bug has been fixed in 5.0 beta6a. Unfortunately, this one doesn't support 3TB drives, so I can't check this.

Chris

Chris

... the thing is that the disc is not doing anything. The activity LED is off, and it looks like nothing happens.

 

I love this forum. People here are really interested in helping each other.

 

Thanks for that.

 

Chris

 

... and I also can't find a process via 'ps -ef' that seems to work on the "UPGRADE_DISC" task.

 

I guess the problem has been described before:

 

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

 

But in the last post it is stated the bug has been fixed in 5.0 beta6a. Unfortunately, this one doesn't support 3TB drives, so I can't check this.

 

Chris

 

Chris

I need to see your system log capture after you have clicked the 'Start' button to start upgrade but then nothing happens.

I have updated from 5b7 to 5b8b, and quickly to 5b8c

 

It would appear that the mover is not shifting files from the cache drive, either automatically or manually. If I activate the mover manually, I can see that the cache drive is being read and one of the data disks is being written to. however the reported space free of the data drive is not reducing.

That seems impossible.

 

I think there is a bug with the refresh of free space.  I've checked this twice now.  Here is what I observed:

1.  Start copy of data with NO cache drive enabled.  Read and write columns show activity for the specific drives.  After copy has completed, the free space numbers do NOT change from before the copy.  Hitting refresh still does not change the values.  Stopping and starting the array updates the values correctly.

2.  Start copy of data with cache drive enabled.  Read write columns show activity for the cache drive.  After copy has completed, the free space amount on the cache drive has not changed.  Manually initiating the mover shows activity in the read write columns.  Once move shows complete I hit the refresh on the main page.  Free space on the cache and target drives still do not change from pre-copy values.  Only stopping and starting the array causes the updated values.

**UPDATE** I forgot to mention that I verified that all files were copied / moved successfully.

Regards,  Peter

Further to my earlier post, this is exactly the same behaviour that I have experienced

I think there is a bug with the refresh of free space.  I've checked this twice now.  Here is what I observed:

Doh!  Right, I see this.  Fixed in -beta8d.