taalas

Hi everyone, a while I started to get a parity error (1) during a parity check. This coincided with an increase in "Reallocated sector count" on my parity drive (from 0 to 1), so I assume this to be the cause. Subsequent parity checks still report the single parity error. My inclination would be to be to start a correcting parity check (writing new parity to the parity drive), since it seems likely that this is the cause for the error. Would you agree or should I analyze something else first or try another approach? Thanks!

Not exactly sure what you mean. Aren't those share settings regarding the default mover? Why should I have to re-do those settings (and how would I have known)? I also did a couple of test runs and checked the logs before running it, the test runs and the productive run behaved completely different though...

I moved from the "old" to the "new" Mover Tuning plugin yesterday and after setting it up and running it I immediately got a minor heart attack: it seems that on my system the plugin does not evaluate the mover action that is set in the share settings. I (historically) have some shares that are set to cache primary, array secondary, but with mover direction set from secondary to primary. The mover plugin ignored this and started moving system files, syslogs and vm disks off the cache to the array. I agree that setting the share like this does not make a lot of sense, but am also certain the mover should not ignore that setting

Thanks for your reply. So as I thought: manually run mover, check if all files are off the cache, then change?

Hi! This might be kind of a trivial question: Since one if my cache drives is failing I would to to change the primary storage (cache) for some of my shares (i am on 6.12.1). Will this "just work" if i change it in share settings? Or should I make sure to manually run the mover, check that all files are on the array and then switch over?

Hi itimpi, that's indeed what was happening. There was an empty folder called "fastappdata" on my cache pool named "cache". What confused me in the end was the wording of the warning, as it states: Share fastappdata set to use pool fastcache, but files / folders exist on the cache pool With "fastappdata" and "fastcache" in bold, but the second part just stating "cache pool" I was thinking about the "fastcache" cache pool, not the other "cache" pool...

I crossposted to the Support Thread to be in the right spot for this question. Sorry again.

Hi, crosstposting from General Support since I didn't realize this thread was here My Fix Common Problems plugin recently started reported a warning for a new cache pool I created and moved files to. The corresponding share is set to "Only: fastcache". Is there any way/log that tells me, which files the plugin is reporting? How do I proceed? Share fastappdata set to use pool fastcache, but files / folders exist on the cache pool Thanks!

Thanks for your reply! I did, all the files are shown to be on "fastcache", hence my confusion. I might have gotten confused about the support thread, because Google led me to a thread for this plugin that was closed and I didn't see the new one. Should I then rather move this question there?

Hi, I tried to post this to the Plugin Support forum but do not seem to be allowed to post there. My Fix Common Problems plugin recently started reported a warning for a new cache pool I created and moved files to. The corresponding share is set to "Only: fastcache". Is there any way/log that tells me, which files the plugin is reporting? How do I proceed? Share fastappdata set to use pool fastcache, but files / folders exist on the cache pool Thanks!

Hi @JorgeB thanks for your support, very much appreciated! Just to make sure I am doing the right thing: I ordered an ASM1064 controller, which has arrived by now. To rebuild the disabled disk I would now do the following: - make a screenshot of my disk assignments - power down the server - replace the controller - start the server - check if all disk assignments are still correct (this should theoretically work although I use a different controller, correct)? - shutdown the array - remove disabled disk - startup the array - shutdown the array - reassign the disabled disk to the slot - startup the array - rebuild disk from parity Is this the correct order of steps? I am still a bit worried about the parity errors the check warned about (before aborting at about 27%). Do I assume these were just read errors because of the controller malfunction? The parity check was non-correcting. Thanks!

This is the part of the syslog where the problems starting (during the scheduled parity check). When I checked this morning, the parity check was paused, disk 1 showed 1550 errors, disk5 showed 169 errors, parity check showed 169 errors (same as disk5). Since the /dev/sdj (my SSD cache) logged the same errors over and over again. I cut the log after a couple of those. Since restarting the array (and copying some files to another server for safety), no more errors were logged on any drive. This was different before the restart, errors on disk5 kept increasing, albeit slowly. Some question to clarify: - Since the array is working fine for now, should I stop using the system or can I read from the array and have the docker applications running? I stopped the mover process to reduce the workload though. - disk1 is almost empty, all data that currently is on the device does not matter. does that help in any way? - Should I wait for rebuilding/etc. until I have the replacement controller? - What should I expect in terms of data loss (since there were parity errors logged)? Sorry, just trying to get a clearer picture of the situation. syslog-127.0.0.1.log.zip

Hi @JorgeB sorry, I have attached a diagnostic log. I have restarted the server though, since I couldn't access the SMART logs. I can provide the relevant part of my syslog form last night though if needed. It seems to me, that the server might have had problems with the SATA controller the drives are attached to (since in addition to the 2 drives I mentioned earlier, my SSD cache did not work properly). After restarting the server, everything seems fine (except for Disk1 still being disabled). Please let me know whether I can provide any more information. Thanks! spire-diagnostics-20220101-1146.zip

Hi! Last night my monthly parity check started, this morning I found the server with errors: - the parity check is currently paused, since 2 disks have read errors, Disk1 and Disk5 - the array is up (I cannot read SMART values though, "A mandatory smart command failedexiting. To continue, add one or more '-T permissive' options.") - Disk1 is disabled I am not sure what the best way to proceed is right now. Any help would be greatly appreciated.

Thanks @Squid, that sounds like a great idea. Am I right in assuming, that the name of the appdata share is not actually important (as in hardcoded somewhere)? I was afraid of breaking some functionality with using a different share as appdata, but hoped that it was just a share like any other. Also, could you elaborate if there is any up/downsite for using /mnt/fastcache/fastappdata instead of /mnt/user/fastappdata? I have read many different opinions about this...