itimpi

The SASLP-MV8 controller is widely used on unRAID without issues. I have several of them and they work fine. I have found cases where a bad drive takes down the whole controller but that does not seem to be specific to the SASLP-MV8. The other time I have had problems was when I had not seated the SASLP-MV8 perfectly into the PCIe slot (because the backplate was slightly bent). I found that this was very hard to diagnose as the everything seemed to work fine until one put the system under heavy load, but since corrected there have been no issues with that controller.

Found a potential issue with bunker in that if it is running it can stop the array from being stopped. I assume that this is probably fixable by adding a periodic check somewhere to see if the array is being stopped and if so aborting bunker from checking any more files. If anyone knows what can be checked to see if unRAID is trying to stop the array I can probably work out the patch to bunker to make use of the information.

New version 1.14 is made available in the OT together with your additional scripts (these are all located in the zip file). Thanks for your contributions, much appreciated. Glad you were happy with the suggested changes. I would have preferred to PM something like this, but it appears that the forum does not allow attachments with PM's.

Here are yet more improvements to the syslog output for you to check out. I noticed the output was not being tagged as from 'bunker' if they were warning or error messages so have rectified that. I also move some tests into the writer() and Logger() functions that simplified the rest of the code a bit. I have also included copies of my current bunker-verify.sh and bunker-update.sh scripts that I currently run as cron jobs. Not sure if these will be of interest to others? bunker_v1.14.zip

Strange as Cache-Dirs does not actually change anything on the disks. All it does is periodic listings of files/folders to try and keep the relevant directory entries in RAM for performance reasons to improve the experience of browsing the file system. Cannot see off-hand how that would affect Plex.

Files being owned by 'nobody' should not stop them being deleted over the network. You should not need to regularly run the New Permissions tool if the system is correctly set up and configured. Perhaps when you next encounter this problem you can do a command of the form ls -l path-to-files from a console/telnet session and post the results so we can see what the permissions actually are at that point. You also need to get to the root cause of the issue. What is actually creating these files? That is what is likely to need fixing.

I personally actually think perl and python which are large packages should probably not be in the nerd pack which should be kept slim. Perhaps they should each be in a pack of their own?

I think ANY problem with the preclear is an issue. The results of the preclear run should be stored on the flash drive in the preclear_reports folder.

OK - here is the bunker script with the changes I mentioned. I also changed the version number to 1.13 on the assumption that was likely to be what was wanted. Yeah, make your changes and send an update to me. I will make a new version available in the OT. bunker.zip

For your net revision (if any) of bunker I would suggest a small tweak: Adding '--tag bunker' as a parameter to logger in your Logger function Removing the prefix 'bunker -' from the text of the message in all the calls to Logger It makes the syslog output look a little tidier and is more consistent with the style of other messages written to the syslog. If you would prefer a patch to save you work I can produce one for you.

Put your ideas forward, there are definitely more ways to automate the script. Mine certainly is not the only (or best) way. OK - I should have something to look at shortly. When you make a GUI then a good approach is to let the plugin download the zip file from the forum, I have done something similar for cache_dirs. This ensures that people installing the plugin get the latest version of bunker. That was what I was thinking of doing - just checking you were happy before I made any assumptions. There is no exit codes to indicate different failures, results are stored in a log file. Btw bunker is a shell script not a true binary. I had not realised it was a script. I guess that rather than simply suggesting changes I can try providing a patch for you to approve and/or validate. If I still think some exit codes might be useful I at least know how to add such things to a script

Good point. I will have to bear that in mind. At least my assumption is correct and I was not misreading things. Fair enough. I must admit I had only tested it on disks which were primarily video type media files and the total was less than about 10,000 files. Not tried it yet on my music files or software archives where the number would be much higher. I have been taking your scripts and reworking them so that I have a bunker-update.sh script based on your daily one that runs checking for recent changes and handles the adding/updating of the checksums. I am assuming initially that it is run hourly and using -D 6h so that there is quite a bit of overlap but the execution time should still be quite short.[br][br]I was thinking of also having a parameter option to put no time limit on it. The idea is that this one could be used for an initial creation of checksums. It is likely to run for days/weeks on my system with 20 drives to work on but it will take the tedium out of typing commands. a bunker-verify.sh script based on your monthly one that handles verification. The idea is that it is run daily and verifies one disk per day and the disk selected varies each day. This should give a more frequent check than your monthly script as each disk is checked once per month, while still ensuring that there is not too much load on the system. To avoid the most likely times for parity checks I am avoiding the first and last days of the months as candidates for checking the disks. Can you see any reason why this is not a good approach to handling the verification? I am more than happy to pass these scripts back for others to use if they are likely to prove useful. Any thoughts on this, and also am I perhaps likely to be duplicating work you are already planning? Assuming the above scripts work out OK, then I was thinking of trying my hand at a plugin to put a GUI front-end on the installation, configuring and scheduling execution of bunker. If I get that far (which is not at all guaranteed ) do you have any objections about me including the bunker binary as a download in such a plugin or should users just be prompted to install it manually? BTW: Are there any useful exit codes from the bunker binary that it might be worth checking for? I was thinking in particular of codes indicating error conditions.

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?