cybersteel8

Members
  • Posts

    28
  • Joined

  • Last visited

cybersteel8's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. I am going through my disks and viewing the Date of Purchase and Warranty Period information ensure it is correct, I have noticed that for some reason, they have all disappeared. This is for all disks in my array, including my parity disks. I have gone through and set all the dates and warranty periods, but when I go back and check, they've disappeared again. I can do it for a single disk, but once I have done two or three of them, the first one is gone. Something about this feature is not working. I am referring to this: cyberserver-diagnostics-20220621-1901.zip
  2. Ah, so a btrfs scrub actually documents the names of the files that are corrupt? That's incredibly useful to know, thanks!
  3. Thanks. Due to the following test, I have now run a correcting parity check, and it corrected the 5 errors. I have done this and the results seem successful. After the correcting check, I ran a non-correcting check immediately without rebooting at all. There were no errors detected in the non-correcting check. Would the diagnostics still be useful, considering the second parity check resulted in no errors? I am unsure if it is safe to assume that my hardware is fault-free, but I suppose if I keep getting parity errors, diagnostics would become more useful. I think this is something I will keep an eye on, but not worry about. I'd like your opinion on this. -- It seems the answer to my original question is that, when a non-correcting parity check results in errors, no action is taken by Unraid. A second parity check will show the same errors. The action that ought to be taken by the user is to run a btrfs scrub on all of the array drives to determine if there are any problems with the data on the drive. If the btrfs scrubs result in no errors, then the errors are on the parity drive, so a correcting parity check is appropriate. Another non-correcting parity check after correcting parity is appropriate, to ensure that parity is indeed in a valid state. "If there are errors as a result of the scrub, then that drive should be rebuilt from parity, as the parity mismatch is from the data not the parity" - This is my assumption. I would appreciate a comment on this to know if my assumption is correct.
  4. My last good parity check was a month ago, and unfortunately I have rebooted since then, as I upgraded from 6.9.2 to 6.10.1 and that requires a reboot. It was not unclean.
  5. I still don't know how to determine which files are affected. I don't even know which drive I would want to rebuild, if I took this approach. How do I know which files are affected? Thanks. I have done this on all my array drives, and no errors were found on any of them. Does this mean the error was on the parity drive and not on my data drives? Do I know this with confidence?
  6. I am using btrfs - how do I find out if the errors are in data or parity? I understand that a correcting parity check will update parity, but what if the errors are in the data, not the parity? How would I fix the data using the parity information?
  7. My monthly parity check completed with 5 errors. This is in my syslog: kernel: md: recovery thread: P incorrect, sector=1962934168 kernel: md: recovery thread: P incorrect, sector=1962934176 kernel: md: recovery thread: P incorrect, sector=1962934184 kernel: md: recovery thread: P incorrect, sector=1962934192 kernel: md: recovery thread: P incorrect, sector=1962934200 [...] kernel: md: sync done. time=82684sec kernel: md: recovery thread: exit status: 0 There is no other messages in my syslog related to the parity check. I don't actually know what happens now. Unraid says there were 5 errors, but all my disks are still active, nothing's simulated or whatever. What action did Unraid take once these errors appeared? As it was non-correcting, did nothing happen? It just reports them and that's it? Which files are these in particular - is there a way to know? Do I need to know? I don't know what action I take once errors appear in the non-correcting parity check.
  8. I successfully updated from 6.9.2 to 6.10.1 I was initially concerned when looking at the Main tab, seeing all my drives mounting one by one with 0TB, but after the Array finished starting up, everything is fine. So don't be worried if you notice this! I really like the new dashboard graphs, and the btrfs schedule-able features. Very exciting!
  9. Hi all, I am new to using the Dynamix Auto Fan Control plugin, and I would like to ask - can this plugin control multiple PWM controllers at once? I have my fans plugged into different pins on my motherboard, so they are independently controllable. Can the plugin modify the fan speed of all of these fans, or only one controller?
  10. Ah, so the answer to my first question is that it is running as if it was unticked, which is the behaviour I want. So there's is nothing I need to change! Thank you!
  11. Hello all! This is quite a convenient thread, though I didn't find the answer to my question so I hope I'm not asking the same thing as somebody else. I experienced an unclean shutdown due to a power outage, and when the power returned and the server came back online, it mounted the disks and began a parity check automatically (as expected). I would like to ask - when starting a parity check manually, the "write corrections to parity" is ticked by default. When the parity check starts automatically, is it starting with this ticked or unticked? How do I found out and control this behaviour? Furthermore, I am under the impression that unless I want to correct the parity data, I should untick this option when doing parity checks. This is so that any corrupt data on the data disks can be fixed using the parity data. As this is likely when there is an unexpected power outage, I believe that it would be proper practice to perform the automatic parity check without writing corrections to parity. Is my assessment correct? Thank you all!
  12. Indeed. Though, I think I need to point out that this is a Plex issue, not an Unraid one. This thread was started and bumped because of Unraid's support for this CPU. It supports it and hardware acceleration is available for Plex.
  13. I am indeed having trouble with HDR to SDR tone mapping (the transcoder is failing completely), but QuickSync is indeed working when doing SDR content, both 4K and 1080p. The gpu driver is being forwarded to Plex and Plex's transcoder is indeed hardware accelerated. If you experience any problems with HDR transcoding, turn off HDR Tone Mapping in your Plex Settings > Transcoder section.
  14. Hey mate, yeah, I got QuickSync to work perfectly fine with my i5-11500 I did need to install the intel_gpu_top app from the Community Applications plugin to get QuickSync to work. I also had to pass the /dev/dri directory to the Plex docker container as well. Check out the instructions regarding that docker path variable here:
  15. I am curious about the benefit of setting the system share on Cache Prefer. I use the tool that backs up my appdata onto the array (as it is also cache prefer) but I don't have such functionality for the system share, so it currently only exists on the single cache disk I have. I would like to know if there is any benefit in keeping this share on the cache at all times - in other words, is the docker.img file that is inside it constantly in use while docker containers are running? I only restart my docker containers when there is an update to be applied, and I assume that is when the docker.img file is used. But otherwise, is the file in use at all? If it isn't, then there's no point keeping it on the cache, right?