John_M

False positives resulting from pre-clear reports: Jan 13 21:40:33 Northolt preclear_disk-diff[52582]: #011#011#011#011#011without error or no self-test has ever Jan 13 21:40:33 Northolt preclear_disk-diff[52582]: #011#011#011#011#011SCT Error Recovery Control supported. Jan 13 21:40:33 Northolt preclear_disk-diff[52582]: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE Jan 13 21:40:33 Northolt preclear_disk-diff[52582]: SMART Error Log Version: 1 Jan 13 21:40:33 Northolt preclear_disk-diff[52582]: # 1 Short offline Completed without error 00% 89 - I guess it's the word "error" that's being caught as an Error, and the word "WHEN_FAILED" that's being caught as a Minor Issue.

Jan 10 18:20:50 Lapulapu kernel: xor: automatically using best checksumming function: Jan 10 18:20:50 Lapulapu kernel: r8169 0000:04:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] Both are being flagged as Minor issues. Is it the word "checksumming" that's causing the false positive, for some reason?

Check your parity drive's settings (Main|Parity) and make sure that the Spin down delay hasn't inadvertently been set to Never. I had a data drive that would never spin down and I discovered this setting had somehow been changed from Default. It may not be the case for you but it's an easy thing to check.

There's something I may have misunderstood, so I'm running my tests again, regarding my .DS_Store problem. Can I just check something, please? Under the File Integrity Control tab, am I right in thinking that the Check button initiates a check of the files against their exported checksums and not against the checksums stored in the extended attributes and it isn't a manual equivalent of the scheduled daily/weekly check, which does use the extended attributes? If I am right, then what is the result of clicking the Check button without ever clicking the Export button? Could that explain the "bunker: warning: is missing" messages in my syslog? I've stopped adding files to my shares for the time being and I've run Build again, and then Export. My disks now have both Initial Build and Initial Export green checks. I'm running Check at the moment and hope to see no errors this time. Nice plugin, btw Many thanks. EDIT: The manual check has completed with no errors reported. I'll use the server as normal and see if any errors are reported after the scheduled check on Sunday.

I'm getting checksum errors reported on Macintosh .DS_Store files. It seems possible that when I add files to a folder on my unRAID share using the OS X Finder the .DS_Store file within that folder is being updated but its checksum isn't, which results in the file corruption messages. unRAID file corruption: 07-01-2016 09:49 Notice [LAPULAPU] - bunker check command Found 6 files with BLAKE2 hash key corruption Syslog snippet: Jan 7 03:52:47 Lapulapu bunker: warning: is missing Jan 7 03:52:48 Lapulapu bunker: warning: is missing Jan 7 03:58:18 Lapulapu bunker: warning: is missing Jan 7 03:59:04 Lapulapu bunker: warning: is missing Jan 7 04:24:40 Lapulapu bunker: warning: is missing Jan 7 04:25:03 Lapulapu bunker: warning: is missing Jan 7 05:48:36 Lapulapu bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/L_Public/.DS_Store is corrupted Jan 7 05:48:36 Lapulapu bunker: warning: is missing Jan 7 05:48:36 Lapulapu bunker: warning: is missing Jan 7 05:52:11 Lapulapu bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/L_Public/Shared Videos/.DS_Store is corrupted Jan 7 05:53:22 Lapulapu bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/L_Public/Shared Videos/DVD Rips/.DS_Store is corrupted Jan 7 06:53:48 Lapulapu bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/L_Public/Shared Videos/DVD Rips/3 MKVs/.DS_Store is corrupted Jan 7 07:08:10 Lapulapu kernel: mdcmd (68): spindown 0 Jan 7 07:08:11 Lapulapu kernel: mdcmd (69): spindown 2 Jan 7 08:12:44 Lapulapu bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/L_Public/Shared Videos/EyeTV Archive/.DS_Store is corrupted Jan 7 09:15:00 Lapulapu emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin checkall Jan 7 09:45:16 Lapulapu bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/L_Public/Shared Videos/MakeMKV/.DS_Store is corrupted Jan 7 09:49:16 Lapulapu bunker: checked 49978 files from source /boot/config/plugins/dynamix.file.integrity/disk1.export.hash. Found: 0 mismatches (updated), 6 corruptions. Duration: 06:36:46 Average speed: 118. MB/s Perhaps the lines containing "is missing" are a clue. Is there a way of telling the plugin to exclude .DS_Store files?

I downloaded the latest version and it is indeed fixed. Many thanks.

I have an AOC-SASLP-MV8 which produces false positives, the second and third lines below being highlighted as errors, presumably by the presence of the word "error". Is there a way to filter this out, please? Jan 5 00:31:16 Lapulapu kernel: sas: Enter sas_scsi_recover_host busy: 0 failed: 0 Jan 5 00:31:16 Lapulapu kernel: sas: ata9: end_device-1:0: dev error handler Jan 5 00:31:16 Lapulapu kernel: sas: ata10: end_device-1:1: dev error handler Thanks for making the highlight colours customisable. Some of the default pastel shades look too similar to my eyes.

Very nice. It makes searching through a log so much easier. One of the colours used (mid grey) doesn't appear in the legend.

Isn't there some licensing issue (CDDL vs GPL) that prevents ZFS from being distributed with the Linux kernel? I'd rather stay with BTRFS, myself.

I know from the smiley that it was said in jest, but it wouldn't be a Red drive if it was based on SMR technology (I'm guessing that's what you meant and the "P" is a typo). It would be something else and they'd have to invent some new colour for it - Orange, say - because SMR drives are not suitable for the same applications that define the Red range. The first generation SMR drives, produced by Seagate, are designed to emulate conventional SATA hard drives while being very different internally. In order to make them as near as possible a drop-in replacement the complexities of the SMR technology are handled by the drive's own firmware. The need to flush the persistent cache is hidden from the operating system and so the drive appears to become very unresponsive for several seconds at a time. This is usually enough to confuse a RAID controller and cause it to eject the drive from an array. Hence Seagate's own recommendation that they be used singly. unRAID, of course, isn't RAID so they may well work reasonably well as data drives, though I don't think they would be best suited as parity drives. Second generation SMR drives, such as the 10 TB helium filled HGST product, are host-managed (as opposed to drive-managed) whereby the responsibility for managing the persistent cache is delegated to the operating system or disk controller. The problem is that mainstream operating systems or RAID controllers don't have the capability, yet. But when they do, they will make the best use of the host-managed SMR drive's persistent cache. Current file systems are not optimised for SMR drives - they were designed at a time when seeks were expensive and overwrites cheap. With SMR the situation is reversed, favouring log structured file systems. Reading this thread, it would have been useful if people had mentioned the model of the drive they were discussing because some people were talking about a conventional drive while some were discussing an SMR drive. There are several 5 TB Seagate drives available at the moment, each designed for a particular application. The only one that uses SMR technology has "AS" in its model number, such as ST5000AS001. They work very well in external USB cases and it isn't Seagate's fault if people break open the cases and use the drives as they were never intended to be used. The ST5000DM000, in contrast, is a conventional non-shingled drive.

I've been searching this board for a reliable way to implement a swap space but I'm struggling because it contains a lot of outdated information. I don't want to use reiserfs at all and will stick with the default use of XFS on my data disks and btrfs on my cache disk so after a little thought I came up with the idea of using a swap partition on my cache disk. So I did a bit of searching to see if unRAID supports the idea. This thread suggests that multiple partitions are supported as long as the cache is on partition 1. However this message, while confirming that it is theoretically possible, says that a bug was introduced back in 2011 that prevented it from working. Does anyone know the position with version 6.0.1 in 2015, please?

The plug-in is essentially broken under unRAID 6 because it defaults to creating the swap file on the cache drive without checking the filesystem format on that drive. The cache drive in turn now defaults to being btrfs formatted, which according to the swapon manpage does not support swap files. It gives the "swap file has holes" error. It would be nice if the plug-in checked first before creating the swap file and, on detecting an incompatible filesystem, warned the user and exited gracefully.