itimpi

That would only happen if no file system superblock can be found and the repair process starts looking through every sector on the disk to see if it can find a backup copy. This sometimes works but also often means that the file system corruption is sufficient to stop the repair process working. Any rebuilt drive would have exactly the same behaviour as it is simply a sector-for-sector copy of the emulated drive. That is one reason why it is recommended you try to repair the emulated drive first as a successful repair only takes a minute or so. If you cannot repair the emulated drive you will not be able to repair the rebuilt one either.

The problem is that even an disk with no files but has been formatted to create an empty file system (what a user normally means by an ‘empty’ disk) is included in the parity calculations and cannot be removed without invalidating its role in the parity calculations. This would mean that there is no longer enough redundancy information to allow disk10 to be rebuilt. this is one reason why it is frequently recommended to not add a disk to the array before you require (or will soon require) the space. Once added the drive is no longer available to be used as a replacement for another drive that then fails.

The rebuild puts on a replacement disk exactly what unRaid thinks is on the “emulated” disk. You can therefore run the file system repair against the emulated disk BEFORE putting in a replacement disk. If the repair of the emulated disk does not work then not much point in rebuilding as the rebuilt disk will have the same problems and you need to try an alternative method of getting your files back (e.g. original disk, backups). What was showing while it was scrolling? This is not normal and in most cases the xfs_repair is a very fast process.

You can click on the folder icon at the right hand end of a drive entry on the Main tab to browse the contents of a particular drive. You can also go via the Shares tab and browse via the folder icon for that share - it will show you for each entry exactly what drive(s) is involved for any folder/file.

Parity2 cannot be built without reading all the data drives as it uses a different calculation to that used for parity1 so not sure why this did not show up Not unless you have a really low spec CPU that struggles calculating the parity values fast enough. All modern CPUs will be constrained via the drive speeds so it is the size of the largest parity drive that determines the time taken.

You are correct in that moving files between shares on the SSD drive should have been virtually instantaneous so the fact it is not suggests something else is going on. have you checked: that both the source and target DO finish up on the same SSD drive that there is not some additional action being taken (e.g. extracting or decompressing the download) that is taking the time.

You might want to reset the timeouts for closing down Docker and VMs by going to their respective Settings page (you may need to enable Advanced vie at the upper right to see the timeout setting) as there have been reports of unRaid not honouring these settings until you do this. You should also try stopping the array first to see how long that takes in case the timeout values (particularly for VMs) need increasing. If the array successfully stops This should mean you do not get a parity check started the next time the system boots. If you still get a parity check on starting after successfully stopping the array up then this suggests a flash drive problem where unRaid was unable to record the fact it had successfully stopped the array. If you cannot successfully stop the array then you need to investigate what is stopping that from happening.

No - it was a write failure as that is the only time unRaid disables a drive. The write failure could have been triggered by a read failure which subsequently caused unRaid to then try and correct it by rewriting the sector it had just failed to read and that write failed.

Not much difference between your options as both of them require every sector on the disabled parity disk to be accessed. The only difference is that in one you are reading every sector and in the other you are writing them. I personally would go with rebuilding parity as since you have already had a write to the drive fail (which is why it was disabled in the first place) you now want to know if you can reliably write to that drive without errors as if not the drive will need replacing.

This is how I handle my servers without using the S3 Sleep plugin. I would have thought any modern PC will have an option in the BIOS to power on at a given time.

I regularly include links in forum posts so not sure why you are having problems. Are you using the option on the edit toolbar to insert a link or are you doing something different?

Not much point in doing a preclear unless you are doing it as a confidence test of the drive. The rebuild overwrites every sector regardless of its current contents.

I think it is never wrong to periodically bring this up as it would be a nice enhancement if mover could be made somehow to use the size of a file it is about to move as one of the selection criteria for the target disk. It cannot be trivial to do or I am sure it would have already happened but it does seem a good idea to have as a potential roadmap item. Limetech did announce a while ago that /mnt/user0 was deprecated and could disappear in a future unRaid release so presumably they have thought of some other way of working that will not need it?

I see a message in the syslog about too many devices connected and as a result the array non being started - you do not by any chance have a removable USB device plugged in? Not sure about your connection issue Maybe the Value "invalid" is not no/yes. indicates there is an error introduced in the MyServers support? Have you tried connecting directly via IP using http://192.168.1.44 It also looks like you do not have a password set for the root user - this will stop you being able to make SSH connections on the latest unRaid releases due to tightened security.

It looks like there should be a recommendation to only use the Search option if you cannot find it without using the Search option. When you used the Search option it showed you an old wiki entry that is not part of the ‘Manual’ that Limetech are trying to maintain and update.

That looks like an error trying to read a trial key file off the flash drive. I would suggest over-writing it with another copy as that often fixes such issues if it is just a borderline sector on the flash drive.

Not clear to me if you have run a correcting parity check to completion since using the wrong variant of the xfs_repair command? That would certainly have resulted in parity errors that would need correcting. Looking at the diagnostics the last check was correcting and unRaid confusingly reports each corrected sector as part of the error count.

Strange you ended up there if you went via the Manual link. The section of the manual that describes replacing a disk is here under Storage Management.

if you had clicked on the drive before starting the array to add the drive you would have had the option to explicitly set the format you want.

the best place to start is often the ‘Manual’ link at bottom of the unRaid GUI.

After using New Config you can reorder the disks with no problems as long as you are not going to assume parity remains valid. unRaid will build parity based on the assignments at the point you start the array.

The process is described here in the online documentation that can be accessed via the Manual link at the bottom of the unraid GUI.

The default of RAID1 gives redundancy which is why you are limited to the smallest drive for available space. If you do not care about redundancy then you can use all the space as described in the link given above.

Not sure why you think this? Works fine for me.

Hopefully clocking the RAM slower will help. Many people do not realise that the CPU/motherboard combination can impose a lower safe clock speeds than the RAM is rated for, and that the number of RAM slots in use can also impose limits.