itimpi

No - reads from full reiserfs disks should not be affected by the performance degradation that affects writes on full disks. Is the USB drive that you are trying to write to connected via USB2 or USB3? It may well be that end that is actually turning out to be the limiting factor. Also, what format is that drive?

I think it actually creates a GPT partition structure that has some ridiculously high limit on maximum size - there is just the protective 2TB MBR first partition to keep certain software happy. This seems to be normal for disks larger than 2TB.

Just for information, I have found that often nothing shows in the noVNC client that can be launched from the unRAID GUI, but if you use a local client such as TightVNC or UltraVNC and point it at the UnRAID server IP and the port shown in the GUI for a particular VM it works. I must admit I am not sure why this happens (and would love to see it resolved as using the noVNC client is convenient) but at least it may give you a way forward.

I would expect that the drive is OK as the pending sectors went back to 0 and there are no reallocated sectors. However probably a good idea to keep an eye on it just to check it stays there.

I see that the Sandisk Ultra Fit seem to be USB 3.0 drives. There have been lots of reports in the past about issues with USB 3.0 flash drives. Even when working with unRAID they have often needed to be plugged into the USB 2 sockets.

If the drive is eligible for RMA then I would suggest that you go ahead and do it. Ideally you want any Pending sectors to go immediately to zero on a pre-clear run. The fact they do not suggests some sort of lingering problem with the drive.

I have never had Seagate query a RMA in practise. If they were reallocated sectors that would be one thing, but sectors that cannot be read or reallocated would be another I would think as that makes the disk unfit for use.

Pending sectors are a bad thing as they indicate sectors that cannot be read properly. However it is not at all unusual for them to be cleared when they are next written. I would suggest that you might want to consider temporarily removing the parity disk from the array (however note that leaves you unprotected against another disk failing) and put it through a pre-clear cycle to see if the pending sectors resolve themselves. If it does then you are probably OK with that drive although it will bear watching. It not then you want to look into an RMA for the drive. If you have another spare disk of sufficient size you could put it in place of the current parity disk and let parity build onto that drive instead.

KVM has the concept of the 9p drivers. However users are finding that it does not seem to provide better performance than going via the network, and can also causes problems with permissions on folder/files.

I think t does if you do it through the GUI. However you bypassed that process by creating the folder manually. Not sure if it should refuse to create an automatic share for a folder with a reserved name - that might be sensible.

unRAID automatically creates a share if it finds a top-level folder. One issue is that in Linux case is significant while Windows ignores it and this can lead to unexpected results sometimes. You probably need to check each disk to see if you have appdata top level folders with different capitalization, and if found they need to be made to exactly match the share name you have set up..

Yes - you can have any mix of the supported file systems.

Yes - if you replace a drive with a larger one then the rebuild that takes place gives you the same file system - just with more space. It does not allow you to change the file system type at the same time - as a few who thought it might have found to their cost

The boot menu details is specified by the 'timeout' entry in syslinux/syslinux.cfg on the boot device. It is a text file, but make sure you edit using an editor that understands Linux end-of-line (e.g. notepad+).

You do not mention how much spare space you have on the array? If you have enough then it is possible that moving data between drives could free up a drive to start the migration? If you do not have the free space then maybe now is not the right time to do the migration? You might want to wait until you intend to install larger drives (which would give you the space you need for the migration). As was mentioned the alternative is to temporarily store files external to the unRAID system to free up the required space.

That dd command failing to read any data from the disk is definitely worrying. I would be extremely cautious about assuming this drive is OK at the moment. Maybe the next step is to use smartctl to run some of the self-tests (which I see have never been run) to see if they complete OK. The dd results suggest to me that even the short test may fail.

Also a screen session can cause this - easy to forget they might still be hanging around

Have you tried logging in via telnet and following the suggestions in the syslog? It is saying that something is still using /mnt/user and if you have a look you might be able to work out what it is.

Yes v5 only supports Reiserfs. Note that v6 still supports Reiserfs - it is just that the default is now XFS (with an option for BTRFS as well). It is perfectly possible in v6 for different disks to be on any mix of the supported file system types. Switching the file system type for existing disks already containing data DOES need to go through the empty/switch route if you want to convert a disk from Reiserfs to XFS.

Replacing a drive with a bigger drive without breaking parity is already available and has been for a very long time. During this process the array is actually unprotected, but as long as you still have the old drive you can still revert to the protected state if anything goes wrong. I am not sure that your idea of having the old drive and the new one both plugged in and cloning actually adds any significant value, and it seems it could add a lot of unnecessary complexity.

I would expect it to take longer as on a parity protected array, each write actually involves two reads and two writes. You can speed things up considerably by running without a parity disk while doing this and then regenerating parity afterwards, but doing that leaves you susceptible to data loss on a disk failure.

Never really noticed that as I do not use exFAT. I believe that exFAT is primarily designed for flash drives, and on those I tend to use FAT32 instead. I have no idea what the state is at the Linux level for exFAT drivers and whether they are even available for Slackware (which is what unRAID is at its core).

You want to install the SNAP plugin to help with this. There is talk of integrating SNAP functionality into the base unRAID system, but I expect if it happens this will be post the 6.0 release.

Whether it is safe or not I do not see the point! You want to run it on a system that is not running anything else as otherwise the results are likely to be inconclusive. Therefore the dockers and VM's should really be stopped when running the script.

It depends on whether the disk is mountable. It is possible that there was file system corruption and something like reiserfsck might first be needed to correct that. If you have a USB-SATA adapter/case then you could fix this issue on the unRAID system itself.