unRAID Server Release 6.1.6 Available

[bonienl]

ran it. log file now has just the one entry:

 

Dec  2 02:45:40|0|0|0

 

Is the parity check information still in your syslog and you deleted the old log file?

 

Yes I deleted old file. There has been a reboot (6.1.6 update) since last parity check so current syslog does not have the parity check finish in it. Previous log backup has this entry:

 

Dec  2 02:45:40 Tower kernel: md: sync done. time=94538sec

Dec  2 02:45:40 Tower kernel: md: recovery thread sync completion status: 0

 

Since it is not in the current syslog anymore, it can't be added automatically to the history, but you can edit the file parity-checks.log manually (use a linux capable editor) and add the line

 

Dec  2 02:45:40|94538|84.6 MB/s|0

 

[interwebtech]

Since it is not in the current syslog anymore, it can't be added automatically to the history, but you can edit the file parity-checks.log manually (use a linux capable editor) and add the line

 

Dec  2 02:45:40|94538|84.6 MB/s|0

 

Excellent. Thank you.

[sparklyballs]

ran it. log file now has just the one entry:

 

Dec  2 02:45:40|0|0|0

 

Is the parity check information still in your syslog and you deleted the old log file?

 

Yes I deleted old file. There has been a reboot (6.1.6 update) since last parity check so current syslog does not have the parity check finish in it. Previous log backup has this entry:

 

Dec  2 02:45:40 Tower kernel: md: sync done. time=94538sec

Dec  2 02:45:40 Tower kernel: md: recovery thread sync completion status: 0

 

Since it is not in the current syslog anymore, it can't be added automatically to the history, but you can edit the file parity-checks.log manually (use a linux capable editor) and add the line

 

Dec  2 02:45:40|94538|84.6 MB/s|0

 

so when this is ironed out, am i right in thinking it's something to keep parity stats after a reboot ?

[JonathanM]

Is the history button theoretically supposed to be available during a parity check?

[bonienl]

so when this is ironed out, am i right in thinking it's something to keep parity stats after a reboot ?

 

You mean stats as in history graphs?

 

[bonienl]

Is the history button theoretically supposed to be available during a parity check?

 

Yes, a new parity check result only becomes available after the process is completed (or aborted).

 

[sparklyballs]

so when this is ironed out, am i right in thinking it's something to keep parity stats after a reboot ?

 

You mean stats as in history graphs?

 

that would be awesome as all hell, but was thinking more of that whole parity check duration unavailable after a reboot etc.

[bonienl]

Who knows, maybe one day I update the Dynamix Stats plugin to graph parity check times

 

With the current implementation the latest parity check result will be shown, even after a reboot (provided it was saved in the History file in the first place).

 

[bkastner]

Who knows, maybe one day I update the Dynamix Stats plugin to graph parity check times

 

With the current implementation the latest parity check result will be shown, even after a reboot (provided it was saved in the History file in the first place).

 

As a quick suggestion... for those who want to maintain historical checks as long as you have notifications turned on you should be emailed the results of parity checks. While I agree it's nicer to have it all stored in UnRAID I can go back through months of parity check results via the email route, so it's not such a huge deal.

[Addy90]

I really appreciate the new SMART disk settings, but they do not work with RAID controllers though one can set the "glue smType" setting...

 

For example, when I set the Device to "3ware" and Port to "0" the command "-d 3ware,0" is correctly appended in the smartctl call.

But for the call to work, one also must use the /dev/twaN virtual devices instead of /dev/sdX as I already mentioned here:

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

 

If one is not using the virtual /dev/twaN (or /dev/tweN or /dev/twlN device, depending on the card), then you get an error message "Read Device Identity failed: Input/output error" when using the /dev/sdX device.

 

So what is still missing is another field where one can replace the device (that is used in the $port variable) with /dev/twaN (for example /dev/twa0 instead of /dev/sdb in my case).

Another additional "custom device port replace field 'smDevice' f.e." and a small "$port= isset($disk['smDevice']) ? $disk['smDevice'] : $port;" before the $port variable is used in any smartctl command in the SmartInfo.php would solve it perfectly!

(so $port only is the part after /dev/ - you would set twa0 or twa1 and so on instead of sdb, sdc, etc... but not the full /dev/twa0 - so only the twa0 part in the GUI should be possible to set)

 

Nevertheless, thank you a lot for your effort in implementing a nearly perfect solution for handling all different RAID cards - it is really nearly perfect in my case

[trurl]

Who knows, maybe one day I update the Dynamix Stats plugin to graph parity check times

 

With the current implementation the latest parity check result will be shown, even after a reboot (provided it was saved in the History file in the first place).

 

As a quick suggestion... for those who want to maintain historical checks as long as you have notifications turned on you should be emailed the results of parity checks. While I agree it's nicer to have it all stored in UnRAID I can go back through months of parity check results via the email route, so it's not such a huge deal.

It already does this doesn't it? My monthly parity check was still on 6.1.4 and I got an email when it finished

Event: unRAID Parity check
Subject: Notice [uNSERVER] - Parity check finished (0 errors)
Description: Duration: 14 hours, 50 minutes, 40 seconds. Average speed: 112.3 MB/sec
Importance: normal

[bkastner]

Who knows, maybe one day I update the Dynamix Stats plugin to graph parity check times

 

With the current implementation the latest parity check result will be shown, even after a reboot (provided it was saved in the History file in the first place).

 

As a quick suggestion... for those who want to maintain historical checks as long as you have notifications turned on you should be emailed the results of parity checks. While I agree it's nicer to have it all stored in UnRAID I can go back through months of parity check results via the email route, so it's not such a huge deal.

It already does this doesn't it? My monthly parity check was still on 6.1.4 and I got an email when it finished

Event: unRAID Parity check
Subject: Notice [uNSERVER] - Parity check finished (0 errors)
Description: Duration: 14 hours, 50 minutes, 40 seconds. Average speed: 112.3 MB/sec
Importance: normal

 

Yes, that is what I was suggesting. For everyone who wants to keep track of old parity check stats, they should still have them in their email provided they have notifications on. It's what I've used for the last several months to keep track of parity check times between different UnRAID versions.

[archedraft]

 

Who knows, maybe one day I update the Dynamix Stats plugin to graph parity check times

 

With the current implementation the latest parity check result will be shown, even after a reboot (provided it was saved in the History file in the first place).

 

As a quick suggestion... for those who want to maintain historical checks as long as you have notifications turned on you should be emailed the results of parity checks. While I agree it's nicer to have it all stored in UnRAID I can go back through months of parity check results via the email route, so it's not such a huge deal.

It already does this doesn't it? My monthly parity check was still on 6.1.4 and I got an email when it finished

Event: unRAID Parity check
Subject: Notice [uNSERVER] - Parity check finished (0 errors)
Description: Duration: 14 hours, 50 minutes, 40 seconds. Average speed: 112.3 MB/sec
Importance: normal

 

Yes, that is what I was suggesting. For everyone who wants to keep track of old parity check stats, they should still have them in their email provided they have notifications on. It's what I've used for the last several months to keep track of parity check times between different UnRAID versions.

 

This may be true but everyone wants the shiny new play toy. "Psssh you still check email logs... I just click a button"

[bkastner]

 

Who knows, maybe one day I update the Dynamix Stats plugin to graph parity check times

 

With the current implementation the latest parity check result will be shown, even after a reboot (provided it was saved in the History file in the first place).

 

As a quick suggestion... for those who want to maintain historical checks as long as you have notifications turned on you should be emailed the results of parity checks. While I agree it's nicer to have it all stored in UnRAID I can go back through months of parity check results via the email route, so it's not such a huge deal.

It already does this doesn't it? My monthly parity check was still on 6.1.4 and I got an email when it finished

Event: unRAID Parity check
Subject: Notice [uNSERVER] - Parity check finished (0 errors)
Description: Duration: 14 hours, 50 minutes, 40 seconds. Average speed: 112.3 MB/sec
Importance: normal

 

Yes, that is what I was suggesting. For everyone who wants to keep track of old parity check stats, they should still have them in their email provided they have notifications on. It's what I've used for the last several months to keep track of parity check times between different UnRAID versions.

 

This may be true but everyone wants the shiny new play toy. "Psssh you still check email logs... I just click a button"

 

Trust me, I am looking forward to this too. I am just saying it's not like we didn't have anything previously.

[bonienl]

 

Who knows, maybe one day I update the Dynamix Stats plugin to graph parity check times

 

With the current implementation the latest parity check result will be shown, even after a reboot (provided it was saved in the History file in the first place).

 

As a quick suggestion... for those who want to maintain historical checks as long as you have notifications turned on you should be emailed the results of parity checks. While I agree it's nicer to have it all stored in UnRAID I can go back through months of parity check results via the email route, so it's not such a huge deal.

It already does this doesn't it? My monthly parity check was still on 6.1.4 and I got an email when it finished

Event: unRAID Parity check
Subject: Notice [uNSERVER] - Parity check finished (0 errors)
Description: Duration: 14 hours, 50 minutes, 40 seconds. Average speed: 112.3 MB/sec
Importance: normal

 

Yes, that is what I was suggesting. For everyone who wants to keep track of old parity check stats, they should still have them in their email provided they have notifications on. It's what I've used for the last several months to keep track of parity check times between different UnRAID versions.

 

This may be true but everyone wants the shiny new play toy. "Psssh you still check email logs... I just click a button"

 

Trust me, I am looking forward to this too. I am just saying it's not like we didn't have anything previously.

 

As a temporary measure you can copy the earlier hot-fix file I have posted to the folder /extra on your flash disk. This will load the fixes upon each system start.

 

[Frank1940]

 

......

 

As a temporary measure you can copy the earlier hot-fix file I have posted to the folder /extra on your flash disk. This will load the fixes upon each system start.

 

I don't have a /extra folder in the root of either of my flash drives.  Should a just create one and copy the file into it?

[Videodr0me]

In pre-6.1.4 it behaved as if md_sync_thresh was equal to md_sync_window-1 (that is immediately queued new 'stripe' each time in-progress 'stripe' completed).  In upcoming 6.2 this setting is configurable on Disk Settings page.

 

As this setting is not in 6.1.6, am I right to assume that it is still on track for 6.2? The new default for md_sync_fresh leads to reduced parity sync speed with the asmedia sata controller I use, setting it back to md_sync_window-1 restores pre 6.1.4 speeds.

[bonienl]

I really appreciate the new SMART disk settings, but they do not work with RAID controllers though one can set the "glue smType" setting...

 

For example, when I set the Device to "3ware" and Port to "0" the command "-d 3ware,0" is correctly appended in the smartctl call.

But for the call to work, one also must use the /dev/twaN virtual devices instead of /dev/sdX as I already mentioned here:

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

 

If one is not using the virtual /dev/twaN (or /dev/tweN or /dev/twlN device, depending on the card), then you get an error message "Read Device Identity failed: Input/output error" when using the /dev/sdX device.

 

So what is still missing is another field where one can replace the device (that is used in the $port variable) with /dev/twaN (for example /dev/twa0 instead of /dev/sdb in my case).

 

I've made an update and added an additional input field which allow to specify the device name, e.g. twa0

 

I like to get your feedback on this. Can you download the attached file which includes the updates and manual install?

 

installpkg dynamix.smart.update-2015.12.03.txz

 

Thanks for your explanations.

 

See update later in this topic...

 

[bonienl]

 

......

 

As a temporary measure you can copy the earlier hot-fix file I have posted to the folder /extra on your flash disk. This will load the fixes upon each system start.

 

I don't have a /extra folder in the root of either of my flash drives.  Should a just create one and copy the file into it?

 

Sure, go ahead and create the folder when not existing.

 

[mgworek]

Since installing this update, if I telnet into my server and manually move files from my cache drive to my main share, it is copying it to my cache drive. So my main share is Media. If i try to move files to /mnt/user/Media, it creates a folder called Media on cache drive. This has never happened before.

 

Under my share settings for Media, use cache disk is set to No.

 

None of my apps that automatically move files to my share are having this problem.

 

If I browse to my share, i see the new files listed but like I said, it is not supposed to use my cache disk.

[JonathanM]

Is the history button theoretically supposed to be available during a parity check?

Yes, a new parity check result only becomes available after the process is completed (or aborted).

I started another parity check after there was a history button available during normal operation, and the history button went away during the check. So, apparently there is something else that needs to be fixed since you say it's supposed to be available during the check to show previous check history.

[bonienl]

Is the history button theoretically supposed to be available during a parity check?

Yes, a new parity check result only becomes available after the process is completed (or aborted).

I started another parity check after there was a history button available during normal operation, and the history button went away during the check. So, apparently there is something else that needs to be fixed since you say it's supposed to be available during the check to show previous check history.

 

I misunderstood your question...

 

During a parity check it will show the progress of the operation, the only button available is to cancel the parity operation.

 

[Addy90]

I've made an update and added an additional input field which allow to specify the device name, e.g. twa0

 

I like to get your feedback on this. Can you download the attached file which includes the updates and manual install?

 

installpkg dynamix.smart.update-2015.12.03.txz

 

Thanks for your explanations.

 

Hi boniel, I installed your update and it nearly works... it seems I we both mixed up the "-d 3ware,N" and "/dev/twaN".

Okay, it seems that the first Port Number actually is the disk device and the "/dev/twaN" device is the controller card.

 

So what happens is the following: At all my disks, I have to set the $port to twa0 (as I have one controller).

And every disk needs the Port number be set to a different one. Now you only support port numbers up to 9 but my cards supports numbers up to 23 (for example).

 

So it would work if the port number fields were no selection but also a free text field (or would go up to 23 in my case, better 27 for 28x RAID-cards, or free textfield for every case).

For example, when I enter on my /dev/sdb disk controller 3ware, Port 0 (= disk) and device twa0 - then I get the SMART data shown correctly concerning attributes, capabilities and Identity (all values correct!) with one exception: the self-test part shows that the disk is "spun down" and I cannot make any tests though when I download the SMART report, I get the correct values.

 

For disk /dev/sdc I am setting 3ware, Port 1 and device twa0 and I get the correct SMART data (except self-test).

For /dev/sdd I set 3ware, Port 2 and device twa0 and it also works.

For /dev/sde I set 3ware, Port 3 and device twa0 and so on.

 

Now I cannot set my disk11 as I need to set 3ware, Port 10 (which does not exist as It only goes from 0 to 9) and twa0.

If I would install a second card, I need to set that card to twa1 device.

 

Other cards have other Port numbers for the disks - propably also more than 0-9 or other device names like twe0 for example, so I guess it would be best to have "free text input fields" and a little help like a line where you can see the final command that would be used (so that the settings will be shown as additional line like "smartctl -a -d 3ware,14 /dev/twa1" for example when you enter 3ware, Port 14 and twa1 for the 15th disk on the second 3ware controller (that would allow to control the command that is used in the background, like when you don't enter twa0 but /dev/twa0 and the $port would be /dev//dev/twa0 then - so a visual confirmation of the command as an additional line above the apply button after applying settings would be great!).

Perhaps its also better not to have three port fields but one port textfield, so that you could add things like 14,2,4 for yourself - that would be most generic. I mean, now I have to ignore the second and third port settings field and only can use the first one for my first 10 disks.

 

Nevertheless, the device field for entering twaN (or others) does work except for the self-test part which still shows "spun down" and does not allow to start any self-tests

 

Thank you a lot for your work!

[bonienl]

Ok, thanks for the feedback.

 

Different controllers use different port numbering schemes ranging from 1 to 3 fields. Hence the reason to have up to three fields (I can actually disable the unused fields).

 

Also the separation character differs, most controllers use a comma (,) but some use a slash (/). I created an automatic selection of the separator based on the controller selection so the user doesn't have to worry about the exact syntax.

 

I can make the dropdown list longer, perhaps up to 31. This has my preference cause it is more user-friendly than a free-form field.

 

To detect whether a disk is standby or active the hdparm command is used, e.g. hdparm -C /dev/sdb. Apparently that doesn't work on your controller. Can you post an output of hdparm for both an active and standby disk?

[Addy90]

Hi boniel,

 

okay, I guess setting it up to 31 should solve the problem - I guess no RAID card would have higher settings...

Btw: Your argument for the user-friendly approach with the port numbers is very fine!

 

Well the hdparm command might never work as far as I see... I get the following output:

root@Tower:~# hdparm -C /dev/sdb

/dev/sdb:
drive state is:  unknown

 

It makes no difference if the drive is really active or not... I have deactivated spin-down completely as it does not work for me.

 

But nevertheless, the smart self-tests should be possible to execute without hdparm, right?