trurl

Post new diagnostics. If we can compare them in syslog, that would tell what the suspects are. RAM is also a suspect if different parity checks result in different parity errors for example.

I don't think there is a button, just accessing the page checks for updates. Maybe a browser problem? If you have an adblocker, whitelist your server. Clear browser cache, try another browser etc.

Sometimes people lose access to the webUI but can still get to the command line on the server or over the network with telnet/ssh. If so, it is possible to get more information that way. But, setting up Syslog Server as explained in that link will let you get some information saved before it "crashes" that you can retrieve later to give to us.

To use the new SSD partition alignment, those disks must be wiped and repartitioned/reformatted. And that new alignment can't be read on earlier versions so you would have to repartition/reformat them back to the older alignment. All this and more is discussed in those linked threads.

This is basically correct as far as it goes, but Unraid IS NOT RAID. There is no striping. Each data disk in the parity array is an independent filesystem containing complete files. Reading is at the speed of the single disk containing the file. Unraid parity is realtime, so write speed is somewhat slower because parity must also be updated at the same time. So, if you have SSD in an array with HDD parity, writes to the SSD (with parity update) can't be faster than the HDD parity. User Shares allows folders to span disks, but files cannot. And cache and other pools are also part of user shares. See here for more about the details of parity updates:

Typically you will want appdata, domains, system shares with all files on SSD cache and configured to stay on cache. This allows dockers / VMs to perform better since writes aren't affected by array parity, and it allows array disks to spin down since dockers / VMs will generally keep some files on these shares open all the time.

I just wanted to know if you could get to the command line while the webUI wasn't working, so you could get us some more information while it is "locked up". There are different situations that sometime get described as "locked up". Since you can currently get to the webUI Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. Also

The sweet spot currently for HDDs seems to be about 8TB in terms of $/TB. Of course it will be different for SSDs, but as noted putting SSDs in an array with HDD parity isn't the best idea. I know some people are running all SSDs in the array, but mixing HDDs and SSDs in the array will impact perceived performance for the SSDs in many situations (writes, parity checks, rebuilds). And they can't be trimmed.

Since this whole thread started from 6.9 upgrade... multiple pools are the main new feature of the latest betas. Just read the 6.9beta25 and 6.9beta29 threads for more about that. Also, these betas have a better partition alignment for SSDs, though this feature is NOT compatible with previous versions. And changing partition alignment requires reformatting so to use this new feature you have to reformat SSDs. And, there are some additional drivers for some hardware, mostly faster NICs I think, and some known issues for some hardware. All explained in these beta threads, so read them.

You agree with my point about not using small drives, so you bought small drives??? And as mentioned, SSDs belong in the pools not in the parity array.

Don't cache initial data load, cache isn't large enough for that. Mover is intended for idle time, default mover schedule is daily in the middle of the night. Making it run more often won't help anything because it is impossible to move from faster cache to slower array as fast as you can write to faster cache. And mover is just more load on the same disks you are trying to write. So, don't cache initial data load. Your cache looks plenty large enough for typical daily use after the initial load. Some people even leave parity unassigned until after the initial data load since parity slows writes to the array.

😁 you must have some really fat fingers or an odd keyboard, those keys are really far apart.

A few are normal after unclean shutdown, but they still must be corrected. Zero is the only acceptable result. If your array isn't in sync you can accurately rebuild a disk.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. Also

Looks like most of your disks are empty or nearly so. And you have a lot of disks. I always recommend fewer larger disks instead of more smaller disks. Each additional disk is an additional point of failure, each additional disk requires more hardware to attach it and more power. And at some point, more disks requires more Unraid license. Also, larger disks perform better than smaller disks due to increased data density, and larger disks are usually cheaper in terms of $/TB. I also don't recommend using older, smaller disks just because you happen to have them. In order to reliably rebuild every bit of a missing disk, Unraid must be able to reliably read every bit of all other disks. So, untrustworthy disks in the array can actually make it difficult to recover data from other disks. Since you don't seem to need all that storage, if it was me, I would just make an array with the 10TB parity and only the larger HDDs, leaving out the smaller HDDs and leaving out the SSDs from the parity array altogether. Your cache pool looks fine, and you might find a good use for those other SSDs in additional pools, a new feature of the latest betas. I have a cache pool for caching user share writes, and a "fast" pool for things that need fast access, such as dockers and VMs. You don't currently have dockers and VMs enabled, but your configuration for those looks good and the shares they use are already on cache where they belong so they will perform better and not keep array disks spunup.

No evidence in diagnostics of any 18TB drive attached to your server, and as noted, it wouldn't be possible to assign a disk that large to an array with only 10TB parity anyway.

Not possible to have a data drive larger than parity, so obviously some misunderstandings. The reason I asked about 10TB parity and 2TB array disks is because I thought you may have had some misunderstanding about how large parity needs to be. No data drive can be larger than any parity drive, but a 10TB parity drive provides redundancy for a large number of data drives, each up to 10TB. So I thought it odd that you had 2TB data drives with 10TB parity. Parity contains no data by itself. Parity is a common concept in computers and communications, and it is basically the same wherever it is used. Parity is just an extra bit that allows a missing bit to be calculated from all the other bits. So, all the other disks are needed to allow parity to calculate the data for a missing disk. Didn't ask that, and in fact, SSDs in general are usually not recommended in the parity array. And there would be little point in having SSDs in an array with HDD parity, since no disk can be written faster than parity. SSDs in the parity array also cannot be trimmed, and there has been some discussion about whether some SSD implementations might actually invalidate parity. Reviewing your diagnostics now.

Some have used UFS Explorer Wish you had asked for advice before doing anything. It was clear you were on the wrong path when you went here: Never heard of anyone even taking that approach, and still don't know what you meant by this: Since Unraid would never have attempted that, what did you see that gave you the idea it wasn't working? For future reference, here is the correct way to rebuild to the same disk: Stop array Unassign disk to be rebuilt Start array with disk unassigned Stop array Reassign disk Start array to begin rebuild There is no formatting or wiping partition. As soon as anyone mentions formatting in the same post as rebuilding it almost always means they are about to make a mistake, or that they already have.

Unraid doesn't format the drive for rebuild, so I don't know what you mean here. The filesystem (format) is part of the bits of the rebuild. Suspect you have an incorrect understanding of the meaning of "format". Format means "write an empty filesytem (of some type) to this disk. That is what it has always meant in every operating system you have ever used. When you format a disk assigned to the parity array, Unraid treats that write operation exactly as it does any other write operation, by updating parity. So after the format, parity agrees the disk has an empty filesystem. Rebuilding a formatted disk results in a formatted disk. And your diagnostics confirms disk1 is empty.

Can you access the command line on the server?

Did you have a paid Unraid license? If you assign all disks exactly as before before starting the array for the first time, then Unraid will take all the disks with their data just as they are. Not sure how much uncertainty there might be in getting the disks assigned exactly as before because don't know enough details about your hardware. Were you using a RAID controller? Unraid IS NOT RAID.

Not clear you actually answered my questions, or if you did I couldn't separate out the simple answers to my simple questions from all the other information you posted. And the other information you posted seems like it may include some misconceptions about Unraid. Probably the best way to answer many questions I might have, and what I should have asked for to begin with: Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Those diagnostics are with the array stopped. Can you post another with the array started? Also, post a screenshot of Main - Array Operation.

If you are remote, then he will be the one with the Unraid server? Not clear from your question that you understand Unraid is a NAS OS and must run on another computer besides the MACs.