gubbgnutten

The corresponding data disk? All data disks are involved in parity calculation. You have mismatch between the parity as calculated by reading all your data disks and the parity as stored on the parity disk, and from your post you seem to have been running like this for some time . I really hope you are aware that this means that ANY data drive will almost certainly have corruption if rebuilt?

Will absolutely try this, thanks!

Nah, MB as 10^20 is hands down the most confusing one, huuuge!

Not entirely convinced that "WTF?" is the optimal subject for your question...

From your posts it is easy to get the impression that you already have decided that it is a bug in unRAID, and that you are focusing your attention on making everything fit your idea of what the bug is rather than on figuring out what the problem is. I would mount the disk as read-only and check the files. I would absolutely not run any correcting checks on the disk, or anything else that writes to it. If the check on the rebuilt drives passed I would expect the originals to pass as well. The last paragraph probably could to be rephrased and clarified.

No. The thing is, unRAID is not really zeroing the added space in the way you think, it is just filling the whole drive based on parity and the other drives. There is no separate zeroing process or indexing for such process. In any case, it is extremely unlikely that unRAID writing zeros to lots of wrong places on drives would only affect file contents and not mess up the filesystems at all. I would mount the old intact drive as read-only and verify some of the corrupted files.

Expand (database, etc.) to for example VM and especially Docker (and space related to dockers with lots of I/O). That should cover the most common cases.

Are you absolutely certain you had good speeds right before upgrading? Just asking because you seem to have a bunch of nearly full ResierFS drives, and ResierFS is known to be really really really slow when it comes to figuring out where on the disk to write new stuff if there is limited free space available. The FCP part doesn't sound too promising, though...

What about the cache drive? Sure you're not using that one?

No, you can't convert a disk to another file system that way.

Backups are awesome! Wiping everything might be overkill, though. You might want to check out unBALANCE.

You should really read the thread jonathanm linked instead. My warning still stands. Sorry if I'm coming off as rude, I am just in a bit concerned. It is not unheard of for users to destroy their data through the terminal. Trying to copy commands you don't understand will get you into trouble. For example, these two commands mean very different things: rsync -a -n /mnt/disk 1 /mnt/user rsync -a -n /mnt/disk1 /mnt/user You might also want to look up what "dry run" means.

Yikes. Sounds like a recipe for disaster! As a rule of thumb - never mix disk shares and user shares without understanding what you doing to 100%. The same goes for using the command line in general, an extra space or the wrong character somewhere can cause massive problems.

Nice writeup. Next time I need to link it I'm sure I will remember where it is Looking forward to see what "auto" can do if and when it is implemented, maybe I can actually stop toggling write mode manually then. ...and even if it is a fault tolerant BTRFS array, keep in mind that the mover is a weak link in the chain (perfectly illustrated by the recent ReiserFS snafu).

Diagnostics from both 6.2 and 6.1.9 for comparison would have been awesome.

Turbo write Ah, the Lounge, now I remember! Thanks!

Parity updates? When rebuilding a disk you are reading from all disks except the one being rebuilt, and that one is only written to. Not only that - everything is read/written sequentially, best case scenario for hard drives. When moving files between disks parity needs to be updated, which means both reading and writing. Hard drives do not excel at this. Spikes are probably due to caching. Turbo/reconstruct write might be of interest, don't have a forum link ready at the moment, but I know there is something nice written somewhere.

Dangerous indeed. The console is incredibly powerful - With great power comes great responsibility. The system folders such as /bin and others won't be a problem, they exist only in RAM and will be created on boot. The contents of your unRAID USB drive, the cache drive and other disks on the other hand... Do you have decent backups?

How about posting diagnostics? Could help to get things rolling here. (See Need help? Read me first!)

It acted like that because you told it to. Obviously not your intention, so why would the system do something like that? Have a look at your command, it ends with a *. That character in that situation will expand and be replaced by something else. Since you were issuing the mv command from the root directory /, the character expanded to the names of files and folders available there and your command line actually turned into something like this: root@UNRAID:/# mv /mnt/disk4/appdata/ /mnt/cache/appdata/ boot dev lib mnt proc run sys tmp var The syntax for mv expects the last parameter to be the destination, and everything else specified should be moved there.

Stable might be imminent, but since limetech already mentioned 6.2.0-rc5 I would not bet on rc4 as final.

Sounds to me like you moved the files in mc rather than copied them, could that be the case? Anyways, copying through a VM on the server should not be noticeably slower than copying through mc.

I believe this is a new recommendation? Can you expand on this in the context of RFS and XFS? Happy to start a new thread if needed as it sounds like quite an important consideration. He prefaced his opinion with "Personally" so I don't think he meant that this was an official recommendation, or even a generally held recommendation, although I believe it may be. Someone who works at LimeTech is allowed to have personal opinions, right? I agree with him that it's always wise to leave some free space, especially if it's ReiserFS involved. I'm not sure we have enough evidence to say the same for XFS. XFS does seem to handle a full disk better than ReiserFS, at least so far. We do know ReiserFS can sometimes have difficulty when too full. "Personally", I like to keep at least 50GB free, on any drive with any format. As a disk gets filled up, it gets trickier to find suitable regions of unused space regardless of filesystem (although ReiserFS is notoriously bad). The time it takes is related to the proportion of the space free rather than the raw amount, hence the classical 10% rule of thumb. This is of course way less of an issue with the typical archive scenario of many unRAID users (including me) where the disk is filled once and then mostly read from. I keep some space free in case things get written to the “wrong” drive due to split levels.

No! If you re-create the file system, a data rebuild will rebuild the new empty file system.

Well, USB boot device is not actually mounting read-only according to the diagnostics, but the file system is set read-only later in the start sequence when it encounters an error in the file system. Unless you tried to access the corresponding data in Ubuntu/Windows, the "perfectly fine" assessment might be unfounded. In any case, the file system needs to be fixed, either through repair (if repairable) or by making a new one.