itimpi

A small improvement to your daily script is to include the lines at the top of the for loop for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 ; do # Only operate on disks that are actually present in this unRAID system if [ -e /mnt/disk$i ] ; then as that removes any need to alter the script to specify the exact number of disks in the system. Also I was wondering if the -D 1 line should specify a larger value in case a parity check was running the last time this script was run and it therefore exited without doing anything? It seems to me that the current version of the script would omit calculating the checksum for that missed day. In fact on a disk where all the checksums are already added, that parameter does not seem to speed things up much at all so maybe it is mainly useful when first building up the checksums?

I created version 1.12 which has a new option -L, this allows bunker to create log entries only when changes are present. See OT for download. Thanks for adding that option. I will test it out today.

Could I request and enhancement to the -l option (perhaps -L) where only lines with non-zero values are written to the log. At the moment with 20 disks in the system I get a lot of entries reporting 0 changes. It would be easier to pick out significant entries if only the non-zero entries were logged.

Just tried that link - and it takes me to a page (on Mediafire) for downloading the ZIP file containing the files needed.

Looks like there could be a buglet in displaying the initial estimated time to complete? I am creating the initial checksums for a 6TB disk, and I started by getting the following displayed: Currently processing file 2 of 3539. Completed: 0.1% [ETA: 13695459:24:16] which is rather an excessive time This later corrected itself to: Currently processing file 10 of 3539. Completed: 0.3% [ETA: 29:03:57]

Please feel free to format and/or reuse as required. Regarding bullet points, I am not against them per-say but think they should be used to make points and to separate steps. I try to avoid adding them to paragraphs that do not need them so that they stand out a bit more when used for organisation purposes.

No - per drive setting is not an option. I think it has been mentioned as an idea somewhere in the Roadmap section of the forum.

I've just added an entry in the Troubleshooting section about docker containers losing their configuration settings due to the configuration folder not being set to be cache only. This seems to have come up a number of times recently in the forum so seemed worth adding? You might want to check that you are happy with the wording I used.

Just a thought - should there be a parameter option that makes bunker display its version number? Alternatively perhaps it could be standard behaviour if the -q option is not used? That would make it much easier to determine what version of bunker one is actually running. I can see that with the provision of some standardised scripts of the sort covered in the recent forum posts that setting up bunker becomes much easier for the average user. You could perhaps include the latest version of the scripts in the standard bunker download to help those people just getting started? FYI: When I created my own version of your scripts I added to the top as comments the meaning of the various bunker parameter options used in the script. Provides a useful 'quick reminder' of what they are without the need to revert to the master bunker documentation. If you include sample scripts in the standard download you might consider adding such comments to these sample scripts?

Both of the logs that were posted are full of I/O errors which I expect is the root cause of your issues. I think they are on device sdd that appears to be in BTRFS format - is that you cache drive? Yes it is. It has an offline uncorrected value of 3. It passes the smart test but it has prefail values on it too. I had plans to change it out soon. Maybe I should do that sooner rather than later? The pending sectors mean that at best you are going to get inconsistent results any time the system tries to read those sectors, and if they are in an important area of the disk could cause all sort of problems. I think you need to get that issue resolved and then see if you still get UI hanging. Those sort of errors are sometime corrected if you run a pre-clear cycle against the disk. Also you could try the manufacturers diagnostic software to see if it can clear the errors.

Both of the logs that were posted are full of I/O errors which I expect is the root cause of your issues. I think they are on device sdd that appears to be in BTRFS format - is that you cache drive?

You can add another row or column to put them in and "turn off" the unused slots so they aren't displayed. Could not see how to "turn off" the unused slots if I added another row. Probably something I am missing. ... On the Data tab in the Preview Server Layout section, click on a slot to toggle it on or off. Thanks - that was easy. I thought I had tried that but obviously not.

You can add another row or column to put them in and "turn off" the unused slots so they aren't displayed. Could not see how to "turn off" the unused slots if I added another row. Probably something I am missing. Another question - I am currently using 2x4GB drives in a RAID-O array to give me a 8GB parity disk. Any recommended way to handle this case where one logical drive at the unRAID level actually occupies 2 slots in the cage layout? Finally I notice that my 4TB WD Green drives and my 6TB WD Red drives display blank in the Manufacturers column - is there anything I can do to get the manufacturer displayed? Is there any information you might need to work out why these might not be displayed?

I have an array with 20x3.5" drives organised in a 5x4 matrix of hot swap bays which are accessible from outside the server. I also have two 2.5" SSD's which are mounted separately inside the server. I would love it if there was a way to indicate these last two drives separately from the main bank (rather like the Flash drive is).

Hit the Log button for the Dropbox container. In the log is given the URL that needs to be run to authenticate the Dropbox container against the account it has been set up for. You can copy paste that URL and run it on a different system - it does not need to be run from the unRAID server (which does not have a browser installed). Note that this is mentioned in the configuration instructions for the Dropbox container shown when you select the Edit option for the container.

As far as I know this message does not stop the diagnostics zip file being created. Have you tried looking in the 'logs' folder on the flash drive to see if it is there? One change I would recommend that is made to the diagnostics script for a future unRAID release is an information message saying that the zip file has been created and giving its exact name (including location). This will help those who run it via the command line.

As far as I know you should just be able to run any Docker container as long as you are prepared to start/stop/configure it from the command line. That is part of the 'magic' of docker. Making a Docker container unRAID friendly involves developing the XML template to go with it so that it can be managed via the GUI. The other thing that most Docker containers that specifically target unRAID share is common base images which keeps the size of the docker image file down.

That feature does not exist as far as I know. Most people tend to have multiple shares so it is not an issue. Having said that I am surprised that you said cache_dirs cannot cache all the files with 8GB of RAM fitted. Are you running other RAM hungry applications?

The only thing that stops you going back is using one of the new options for file systems (BTRFS or XFS) as v5 does not recognise those. There is no hard-and-fast rule. It is just a case of working out how much data you expect to put onto it. It is quite likely that the size you mention would be fine unless you load a lot of data onto via apps in Docker containers or VM's. In most case it is just a case of configuring the relevant Docker containers to point to where your existing configuration settings and data are stored.

The same file can be created using the 'diagnostics' command from a console/telnet session. It will be placed in the 'logs' folder on the flash drive. There is no syntax. Simply type that command press Enter and then when it completes look in the 'logs' folder on the flash drive for the zip file that has been created. I guess my search is broken because I have looked for the "diagnostics" command from the CLI, and I could not find the right syntax. Does anyone have this in case this happens to me again? I would like to be able to dump that diagnostics file onto my flash drive before I power down if this happens again.

The same file can be created using the 'diagnostics' command from a console/telnet session. It will be placed in the 'logs' folder on the flash drive.

Glad to hear that our rambling did not (quite) make you miss this issue. Now to convince Limetech that it is worth including in the mainline release. It might be worth suggesting as a change for a beta release followed by a poll to get feedback? I thought it was a no brainer but at the moment I gather Limetech do not think so.

OK. I think I missed one of the copying stages you planned to do

Up to here is what I would expect. Not sure what I understand what you are trying to achieve here? What you have specified should work but it will end up with all the files that were originally on disk2 now on disk1 and vice versa. I would have expected you to be copying the contents of disk1/t back to the reformatted disk2 to get back the files that were originally there? Is that what you are trying to achieve or have I missed something?

I saw that. I was wondering how many of those commenting had actually tried out your change? It seemed a very simple and intuitive change but maybe that is just my perspective. That is not to say that a bigger discussion is not merited. Since you know what change you made in this plugin I was wondering if you could point out the detail? I was thinking of looking at whether a similar change could be manually 'patched' into the generic support libraries so I could see what it felt like on other screens. That is assuming it could be done at the generic level and will not need change in every screen?