Encrypted disk device disable and content emulated

[leprechaun17]

Good day,

 

Woke up one morning and had disk 2 and disk 3 disabled with content being emulated.

I read the forum and was to rebuild disk 2 onto itself. Unfortunately, disk 3 being encrypted does not allow that process to occur. See attached diagnostics report.

tower-diagnostics-20210819-0851.zip

Would appreciate the help.

[itimpi]

A disk being encrypted should not affect ability to rebuild as the rebuild occurs at a lower level (sector level) than the encryption.   Are you sure you did not mean something else.

[trurl]

There are some things in syslog that caught my attention:

Aug 18 07:22:01 Tower root: Fix Common Problems: Error: disk2 (ST4000VN008-2DR166_ZGY5MC94) is disabled
Aug 18 07:22:01 Tower root: Fix Common Problems: Error: disk3 (ST4000VN008-2DR166_ZDH7QJME) is disabled
Aug 18 07:22:05 Tower root: Fix Common Problems: Error: Unable to write to disk1 ** Ignored

Looks like both disk2 and disk3 were already disabled when you rebooted, so can't tell what happened before that to see why they were disabled.

 

But more puzzling is disk1 was unwriteable, and you chose to IGNORE that? Can you explain?

 

After a lot of messing around with both disk assignments, it looks like you successfully rebuilt disk2. And then there was some more messing around with disk assignments, and at one point disk3 was unmountable, but that seems to have resolved itself, so...

 

Disk3 is disabled, emulated contents are mounted, so it looks like you should be OK to rebuild. If you want a little safer approach, rebuild to a new disk and so keep the original intact in case there are problems with the rebuild.

 

Not related, but why have you given 100G to docker.img? Have you had problems filling it? 20G is usually more than enough, and making it larger won't fix problems filling it, it will only make it take longer to fill.

[leprechaun17]

I did not intended anything else.

Basically, if I stop the array and unassign disk 3, I cannot restart the array to continue with the rebuilt process.

[leprechaun17]

Thanks Trurl,

 

Disk 1 is full hence the unwriteable error.
Regarding docker.img size was related to a Home Assistant unsupported installation issue which is now resolved. I will change back the image size.

So I stopped the array again and unassigned disk 3 and I am still not able to start the array again.

See attached diagnostics file with array stopped and disk 3 unassigned.tower-diagnostics-20210819-1135.zip

[trurl]

10 minutes ago, leprechaun17 said:

I did not intended anything else

What is this a reply to? You can quote the part of the text you are replying to by selecting it and clicking "Quote selection".

 

11 minutes ago, leprechaun17 said:

if I stop the array and unassign disk 3, I cannot restart the array to continue with the rebuilt process.

Doesn't make any sense like that. Maybe a screenshot would clarify.

 

If the disk is unassigned, of course it isn't going to rebuild it, but it should let you start the array since all other disks are enabled.

 

You posted while I was typing this reply so I will reply to your new post in my next one.

[trurl]

3 minutes ago, leprechaun17 said:

Disk 1 is full hence the unwriteable error.

Don't let your disks get completely full. It may corrupt their filesystems if something tries to write to it. In fact, you should keep some space free in case you ever need to repair their filesystem.

 

syslog in these latest diagnostics indicates disk3 still not assigned and no attempt to start the array.

 

 

[leprechaun17]

OK I found the problem to my issue. When you unassign an encrypted disk, you need to typing your passphrase twice to star the array again.

Once I did that, I start the array, stopped it and re-assigned the disk, started the array again and the rebuild process was initiated.

Thanks for help.

 

[trurl]

11 hours ago, leprechaun17 said:

Disk 1 is full hence the unwriteable error.

After rebuild and your array is stable again, you should free up some space on disk1. Typically you should keep several GB free on every disk.

 

Each user share has a Minimum Free setting. You must set that to larger than the largest file you expect to write to the share. Unraid has no way to know how large a file will become when it chooses a disk for it. If a disk has less than Minimum Free, it will choose another disk. If a disk has more than Minimum Free, it can be chosen, and if the file won't fit the write will fail.

 

Cache (and other pools) also have a Minimum Free setting that works in a similar manner. If a pool has less than Minimum Free, Unraid will choose an array disk instead for cache-yes or cache-prefer shares (overflow).