itimpi

The time is probably determined by the speed of the connection of the drive. If possible use USB3 instead of USB2 as that is much faster.

There was a change - disk1 now shows up in the SMART information and shows no obvious problem so the drive may actually be fine. Do the contents of the emulated disk1 look OK? Asking because what shows on the emulated disk is what you end up with after a rebuild. Do you have a spare disk you can rebuild to (safest). If so rebuild to that keeping the old disk1 intact until the rebuild completes successfully (and you can then test its health). If not you can try rebuilding to the old disk1. The processes for both cases are covered here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

Looking at your diagnostics it looks as though you started getting problems on parity2 and then only a bit later on disk1? Problems on 2 drives at the same time is more often not the drive but an external factor with the most common being the power/SATA cabling not being properly seated. The SMART information for parity2 looks OK so that drive is probably OK, but there is no sign of disk1. I would suggest powering down the server, checking the cabling; and then powering back up to see if disk1 comes back online (and if so post new diagnostics so we can see its SMART info)

No idea why you get the problem, but you can use the syslog server as described here to get a syslog that survives a reboot.

Still not clear what the problem is You normally set the Pause time to be before the server load gets high, and then the resume time to be the time during the night after the load has gone down when you want it to resume. Maybe what you need to provide is the pause and resume times you have set and when you actually want the increments to run. It is also not clear to me if you are talking about an automatic parity check after an unclean shutdown or a scheduled one (and if scheduled when it is scheduled to run). it might be worth providing a screen shot of the settings you have (or a copy of the ‘parity.check.tuning.cfg’ file from the plugins folder on the flash drive). It might also be worth mentioning which UnRaid release you are running.

There is no way this plugin would have been the cause of a delay of the sort you describe. The parity check was initiated automatically by Unraid (not by the plugin which never initiates a parity check) and the plugin took no action until it was time to Pause. my guess is you had something else going on. A preclear for instance can cause can cause an apparent ‘hang’ if the GUI is waiting for some disk related action to complete that tries to issue a ‘sync’ at the Linux level as the preclear operation stops the ‘sync’ from completing.

You can set multiple pause/resume times by using the ‘Custom’ option as long as the entry conforms to a rule for a cron entry. I use this during testing. However I anticipated the Custom option to be used when you did not want an increment every day for some reason. However I am not sure from your description why you need multiple times if you only want 1 increment per day. You rely on the normal schedule for parity checks for when you want the check to start (in other words the plugin does not initiate the check) and then set the Resume time to be before the Pause time so that the Pause happens when you want to use the array for other purposes, and the Resume happens the next day (or late at night). For instance on my ‘live’ server I have my Resume time set to 11:30 pm with the Pause set to 7:30 am. That way I get 1 increment of 8 hours per day that runs overnight. Perhaps you need to give more detail on when you have the check scheduled to be started and when you want checks to be paused and resumed.

Normally a much easier solution is to install UPS client software within the VM that is configured to connect via the network to the UPS software running at the UnRaid level and set to shutdown the VM from within the VM. In other words take the same approach as one would take for a physical PC.

Parity is about recovering a failed drive, and has no understanding of the data on any drive as it works at the physical sector level so it cannot be used to recover individual files.

Running a memtest is one of the options on the boot menu that is displayed when booting Unraid.

Are you trying the xfs_repair from the GUI or the command line? If the command line exactly what command are you trying?

Perhaps it is worth a screenshot of the Main tab so we can see what is showing there?

If a disk is disabled then it is ignored by a parity check. In addition if the number of disabled drives is as large as your number of parity drives then the check becomes merely a read check of the remaining drives. Do you have the scheduled check set to be correcting or non-correcting? Non-correcting is recommended so that if you have a drive acting up it does not run the risk of corrupting parity. The main purpose of the chevk is to alert you any time you have a non-zero number of errors during the run to the fact that you may have a problem that needs further investigation.

As was mentioned the Dynamix File Integrity plugin is redundant if using BTRFS as detection of file level corruption is built into BTRFS. One important thing is that BTRFS can detect that file corruption has occurred, but it is still up to you to have a backup process in place so that if this occurs you can then restore a ‘good’ copy from your backups. The same would apply if you use XFS in conjunction with the Dynamix File Integrity plugin.

Would not have thought it was worth moving to XFS if BTRFS is stable for you. The only reason I can think of preferring XFS is if your system regularity crashes as XFS seems to be slightly more tolerant to crashes. However if you are having regular crashes you have a problem that needs resolving iregardless of your file system choice. not sure why you think there are features available for XFS that are not available if you went with BTRFS. If anything I would think it was the other way around.

No reason I can think of that the libvirt.img file should ever be accessed by docker containers (in fact it should not even be visible to them I would have thought!). I have just checked on my own live system running 6.9.2 and see similar behaviour. My guess is they disappear when stopping the VM service as libvirt.iimg then gets unmounted. Feels like feedback is needed from someone closer to @limetech as to whether this is a bug or expected behaviour and if it is expected behaviour the rationale so we understand what is happening. EDIT: Just checked on my development system running 6.10.0 rc2d and am not seeing this behaviour. Not sure if that means this is a fixed bug or the development system is not running whatever triggers the behaviour. Might need temporarily put the live system on that release to see if the behaviour disappears. EDIT2: Just brought my live system online with 6.10.0 rc2d and still see this behaviour.

Where does RedHat become a consideration bearing in mind this is an Unraid forum.

Yes - this is expected behaviour After initial load Unraid runs from RAM so /home is a non-persistent location. if you want anything that is not on one of the drives mounted under /mnt to survive a reboot then you need to take steps to achieve this. The normal way is to put such files somewhere on the flash drive (located at runtime under ‘boot) and then add entries to the /boot/config/go file to put them into their runtime position (or use the User Scripts plugin).

You are very likely to end up with data loss (0 byte files) dues to Linux not realising that source and destination might be the same file.

With 666 GB for Emby and 100GB for docker.img file there is not much free space for anything else The 34GB for Krusader also looks rather large.

Bear il mind that the licence is tied to a particular flash drive, so using a backup would require a licence transfer (which then blacklists the original). It MUST be all capitalsi on the flash drive, and you run it once you have put the Unraid files onto the flash drive.

Lot quite as you ask, but if you turn on Notifications then you will get an email if any potential problems are noticed including SMART ones.

Yes, as long as the flash is formatted FAT32. In practise you can also create a new flash drive and simply copy across the 'config' folder from the backup as the 'config' folder contains all your settings and licence. If this flash drive is new then make sure the flash is labelled UNRAID and then run the make_bootable.bat file from the flash in Administrator mode. Yes - it is part of the 'config' folder. If it is a new flash drive then Unraid will take you through the Licence transfer process on next boot.

Did you try copying the files or moving them? I am asking because you can get strange results using move where the file remains on the same drive but in the new directory (this is a by-product of the way Linux implements move and the fact that Linux does not understand User Shares). You have to do a copy followed by a delete of the original to avoid this effect.

Yes