CarpNCod

Members
  • Posts

    8
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

CarpNCod's Achievements

Noob

Noob (1/14)

2

Reputation

  1. Scratch that. I just re-read the initial post and saw these GPUs are on separate nodes. The 1660ti does indicate it is only getting 4 of 16 lanes though, which why I assumed (incorrectly) they were on the same node.
  2. I would guess that this is because the 1050ti is in PCI bus 1, device 0 and is probably using 8 of the 16 PCI lanes, whereas your 1060 ti is in PCI bus 1, device 1 and is only using 4 of the 16 PCI lanes. You will want to check the documentation for your mobo. Most AMD boards provide 16 lanes for one GPU, and if you add a second, split them 8/4.
  3. I redirect the output of the scrub command to /var/log/scrub_array.log. You can call it whatever you want, it will be overwritten each time the script runs. If you just want to check the status of the last scrub run from the command line use btrfs scrub status /mnt/cache Substitute for the drive you want the status of. It will give you pretty much what is in the log file. You are correct, the point of this is just to let me know there is a problem. If I get a notification that an error has been found, I check the Unraid syslog in the GUI -- Tools --> System Log. Look for errors that look like this: Jul 11 13:10:32 Tower kernel: BTRFS warning (device md3): csum failed root 5 ino 9417 off 0 csum 0xff2f6c6e expected csum 0xfbf6a901 mirror 1 This is showing I had a check sum error on my data disk3 inode 9417. You can then use ls or btrfs to correlate the inode to a file name. I rename the file, and replace it from backup. Then I run a scrub on the disk with the repair option. Finally I go back and remove the renamed file.
  4. I stumbled across this thread after running into a btrfs csum issue, and started looking for a way to schedule a scrub of all the btrfs disks in my system. Big kudos to Constructor for the idea, Helmonder for the script, and Squid for adding the notify part. You guys got me there! I figured I summarize what I did to save folks from bouncing around. I basically used Helmonder's script as a starting point. I don't have notify set up to email me, I rely only on GUI notifications, so I dropped the -m part of the notifiy I copied the script to have one for each disk on my system (i.e. cache, disk1, disk2, etc.), making appropriate changes /usr/local/emhttp/plugins/dynamix/scripts/notify -e "scrub_array" -s "Scrub Cache Drive" -d "Scrub of cache drive started" -i "normal" btrfs scrub start -Bdr /mnt/cache > /var/log/scrub_array.log if [ $? -eq 0 ] then /usr/local/emhttp/plugins/dynamix/scripts/notify -e "scrub_array" -s "Scrub Cache Drive" -d "Scrub of cache drive finished" -i "normal" else /usr/local/emhttp/plugins/dynamix/scripts/notify -e "scrub_array" -s "Scrub Cache Drive" -d "Error in scrub of cache drive!" -i "alert" fi I used crontab -e and added entries at the bottom to run each script at 10 pm starting on the 15th of every month, one disk per day. # # Run monthly cron jobs at 20:00 on the 15th day of the month: 00 20 15 * * /usr/local/emhttp/plugins/dynamix/scripts/scrub_cache &>/dev/null # # Run monthly cron jobs at 20:00 on the 16th day of the month: 00 20 16 * * /usr/local/emhttp/plugins/dynamix/scripts/scrub_disk1 &>/dev/null ... Notifications look like:
  5. I have pre-cleared a new disk, and replaced disk3 that was incrementing errors. So far, it looks like all is right with the world again. Going forward, if I get anymore BTRFS warning csum failed messages, I will run a scrub from the GUI, and then check the syslog for the impacted file before proceeding.
  6. I see now why I didn't see the filename in the syslog -- I had run the btrfs scrub from the command line, rather than running it from within the GUI. I am still getting used to btrfs after having run reiserfs for so long. Having said that, running ls -laiR /mnt/disk3 | grep 9417 should have shown me the filename associated with inode 9417. Lesson learned. I'll run the scrub from the GUI from now on to capture the filename in the syslog.
  7. Thanks for the info johnnie. I never did find what was at inode 9417. I have run a scrub again and this time the filenames were in the log - two .DS_Store files. No big loss, but increasing checksum errors, all on the same disk are. I'm going to swap the drive out ASAP.
  8. I am seeing repeated syslog entries like the following: Jul 11 13:10:32 Tower kernel: BTRFS warning (device md3): csum failed root 5 ino 9417 off 0 csum 0xff2f6c6e expected csum 0xfbf6a901 mirror 1 I have run btrfs scrub -BdrR on the disk with the results: Scrub started: Mon Jul 13 08:03:48 2020 Status: finished Duration: 3:16:01 data_extents_scrubbed: 30134550 tree_extents_scrubbed: 253058 data_bytes_scrubbed: 1973622132736 tree_bytes_scrubbed: 4146102272 read_errors: 0 csum_errors: 4 verify_errors: 0 no_csum: 116992 csum_discards: 0 super_errors: 0 malloc_errors: 0 uncorrectable_errors: 0 unverified_errors: 0 corrected_errors: 0 last_physical: 2018740535296 I checked the contents of the disk for inode 9417 with ls -liR, but find no file with inode 9417. There is no file associated with the inode that is be reported in the syslog. Extended SMART self-tests show no errors. Drive has been powered on for about 1.5 years. An explanation of what I am missing here and suggested next steps would greatly be appreciated.