I swapped out my motherboard, CPU, and RAM today. I added 2 new m.2 SSDs, with the intention to use them as cache drives, in addition to my existing drive. If they worked out well, I planned to use my old cache drive (3TB WD Black) in the data array.

 

Everything seemed fine after boot. All the drives seemed to be in the correct places, with 0 adjustment required.

 

I added the 2 new m.2 SSDs under the Cache Devices section and started the Array.

 

That's when things got ugly. Now, the original cache drive is Unmountable.

Unmountable disks present

emhttp: mount error: No file system (no btrfs UUID)

 

Syslog is showing this mess:

Jun 29 21:25:57 UNRAID emhttp: shcmd (59): mkdir -p /mnt/cache
Jun 29 21:25:57 UNRAID emhttp: shcmd (60): set -o pipefail ; mount -t btrfs -o noatime,nodiratime /dev/sdh1 /mnt/cache |& logger
Jun 29 21:25:57 UNRAID logger: mount: wrong fs type, bad option, bad superblock on /dev/sdh1,
Jun 29 21:25:57 UNRAID logger:        missing codepage or helper program, or other error
Jun 29 21:25:57 UNRAID logger:        In some cases useful info is found in syslog - try
Jun 29 21:25:57 UNRAID logger:        dmesg | tail  or so
Jun 29 21:25:57 UNRAID logger: 
Jun 29 21:25:57 UNRAID emhttp: shcmd: shcmd (60): exit status: 32
Jun 29 21:25:57 UNRAID emhttp: mount error: No file system (32)
Jun 29 21:25:57 UNRAID emhttp: shcmd (61): rmdir /mnt/cache

 

The 2 Docker containers I had running are missing. Two if my shares are missing as well. There are files on the cache drive that have not yet been written to the array. I expect that my docker config file is also on the cache drive as well.

 

Is this recoverable?

Will I just have to check the format box and lose it all?

 

I've done some reading on the forums. Some are saying that unplugging the cache drive could fix it. It did not. Others are saying that you need to change the drive from btrfs back to reiserFS. Not sure how to do that, but, I did run fsck on the drive to see if that might help.

 

Any assistance would be warmly welcomed!

What format was the cache drive before the upgrade?  Your symptoms would be explained if it was XFS, but because you added additional drives to the cache the format was changed to BTRFS (as that is required if you want a cache pool).

 

However as at this point you have not hit the format option (at least I hope not) then the data on the old cache disk should still be intact.  Going back to a single cache disk and setting the format back to XFS would make it mountable again.  You can then get the data off the disk before going back to having a cache pool.

 

@itimpi,

 

Thanks for the reply! No, I have not attempted to format the disk. I had hopes there might be some way to recover from this. The old format was ReiserFS. How would I go about "setting the format back?"

If it were me, I'd install the Unassigned Devices plugin, and see if that will see and mount the old cache drive. Then you could format your 2 new SSD drives in the cache slots, and copy the content from your old cache drive to the new cache pool.

 

Any time there is more than 1 cache slot available in the main GUI with the array stopped, the only format accepted for the cache drive will be BTRFS, so attempting to assign a XFS or ReiserFS drive to one of those slots will show as unmountable and ask to be formatted as BTRFS.

 

@jonathanm,

 

Thanks for the tip on that plugin. I wasn't aware it existed and it's extremely helpful! I was able to mount my old cache disk and copy over my docker.img file as well as my missing shares and some items I'd forgotten were still waiting on the cache disk to be transferred to the array. Now, I just need to resolve the issues with my new cache disk pair. It looks like they also suffered from my aforementioned issue.

Not sure what you are asking. New disks must be formatted before use, is the option to format the cache pool not available?

@jonathanm,

 

After recovering all the data, I re-added the 2 disks as a cache clustered-pair. I was able to force the formatting of the one unmountable cache disk. Then, I added the old cache disk to the data array. I'm now waiting, for who knows how long, for the WebUI to show that the disk is cleared. I wish there was a faster way to do this and still allow access to my shares. >.<

@RobJ,

 

I posted this here due to the seemingly uncommon knowledge that the above behavior occurs when multiple disks are added as cache disks. There should be some kind of "WARNING:" or "NOTICE:" block of text in the Cache Devices screen that indicates what repercussions could be caused with actions therein.

I'm now waiting, for who knows how long, for the WebUI to show that the disk is cleared. I wish there was a faster way to do this and still allow access to my shares. >.<

A little late now, but that's what the preclear script / plugin is for.

 

Depending on your tolerance for risk I suppose you could abort the process, and revert the array back to the way it was with the addition of your new cache pool. That way you could preclear the drive and add it back later after the preclear was complete. Or, you could set a new config and assign all disks where you want them and rebuild parity. You would be running at risk of drive failure until parity is valid again.

@jonathanm,

 

Being that I had already pre-cleared the disk prior to setting it up as the cache disk, I expected to just be able to set it as a data disk and simply format it. I was mistaken.  :'(

@jonathanm,

 

Being that I had already pre-cleared the disk prior to setting it up as the cache disk, I expected to just be able to set it as a data disk and simply format it. I was mistaken.  :'(

Once anything has been changed on the disk, the preclear is no longer valid. A disk is clear when it has only zeroes for content, so it doesn't change the parity equation. A formatted disk is no longer clear, because it has a fresh empty table of contents written to it.

 

http://lime-technology.com/wiki/index.php/FAQ#How_does_parity_work.3F

 

If you are interested.

@RobJ,

 

I posted this here due to the seemingly uncommon knowledge that the above behavior occurs when multiple disks are added as cache disks. There should be some kind of "WARNING:" or "NOTICE:" block of text in the Cache Devices screen that indicates what repercussions could be caused with actions therein.

 

I understand your point of view, and I confess I didn't fully understand your situation, until you mentioned later that the existing Cache drive was formatted as ReiserFS.  Here is what happened, and what should have happened:

 

- You have an an existing Cache drive, formatted as ReiserFS, and you wanted to add additional Cache drives

- Somehow it allowed you to assign the additional cache drives (this should NEVER have been allowed!)

- The system then, because there were multiple cache drives, changed the format for them to BTRFS, which is the only file system format we have that can manage a pool of drives

- It then attempted to mount the existing Cache drive as BTRFS, which of course is not possible, so it reports it as unmountable, which makes its files inaccessible

 

The loss of your shares and dockers were beside the point, as that was completely expected once the Cache drive could not be mounted.  There's no warning wanted for this situation because it should never happen!  I don't know why it let you, and *that* is the bug here, for which I'll post a Defect Report.  unRAID needs to check before allowing a second cache drive to be added that the first drive is unformatted or formatted as BTRFS, not ReiserFS or XFS.  Otherwise it probably shouldn't even show the additional slots for extra cache drives, even if configured for extra cache slots.  The Help should probably say that if you want to add more than one cache drive, the first cannot be formatted as ReiserFS or XFS.  If it is, then its files need to be saved off of it, and the drive reformatted as BTRFS.

Defect Report created here.