ReadyNAS Pro4 will not expand after 4x disk replacement

[xcntalien2]

Hi there - My issue is as follows:

4-bay running 6.9.4 originally with 2TB disks (now 4TB WD Reds)  1x was DOA and there was a delay until I got a replacement., I allowed resync to start & complete for each disk .

The volume has not expanded after the final disk synced. Note that the 6.9.3 manual online doesn't go into any detail of what should/should not happen for vertical expansion in XRAID.

I see the folowing in the rm-expand log:

-- Reboot --
Oct 25 05:38:19 Charon rn-expand[3253]: Trying auto-expand (in-place)
Oct 25 05:38:19 Charon rn-expand[3253]: Considering inplace auto-expansion for data
Oct 25 05:38:19 Charon rn-expand[3253]: Checking if RAID disk sda is expandable...
Oct 25 05:38:19 Charon rn-expand[3253]: Checking if RAID disk sda is expandable...
-- Reboot --
Oct 25 17:52:07 Charon rn-expand[3221]: Trying auto-expand (in-place)
Oct 25 17:52:07 Charon rn-expand[3221]: Considering inplace auto-expansion for data
Oct 25 17:52:07 Charon rn-expand[3221]: Checking if RAID disk sda is expandable...
Oct 25 17:52:07 Charon rn-expand[3221]: Checking if RAID disk sda is expandable...
-- Reboot --
Oct 25 19:18:56 Charon rn-expand[3214]: Trying auto-expand (in-place)
Oct 25 19:18:56 Charon rn-expand[3214]: Considering inplace auto-expansion for data
Oct 25 19:18:56 Charon rn-expand[3214]: Checking if RAID disk sda is expandable...
Oct 25 19:18:56 Charon rn-expand[3214]: Checking if RAID disk sda is expandable...

I've read quite a few community posts...there are no ATA errors on the drives, the volume is healthy and I am in XRAID mode. I have 2x raid groups showing in the GUI.; the first includes all 4x disks and the second only has two disks in it an no allocation used. I am unable to delete the group. The data is accessible but the volume still shows 7.26 TB whereas I  expect it to be  closer to 10.7 TB

I have run btrfs filesystem resize max /data  as root, but this doesn't seem to do anything.

 I have  tried    a balance     but this appears to fail after 1 minute with:

ompleted ERROR: error during balancing '/data': Input/output error

There

NB; the word "There"  is in the log not a typo 🙂

I would rather not factory default and restore from backup; does anybody have any suggestions  to make volume expansion happen please?  I can provide other snippets from logs if required

Thanks,

Stuart.

[StephenB]

If you don't have a current backup, you should definitely update it - partly because your data is at risk, and partly because there is a reasonable chance that you will need to do the default/restore to completely fix your problem.  One aspect is the failure of of the balance - it would be helpful if you could look at the logs and try to find the underlying error for that.  If you are getting BTRFS errors during the balance, the best approach is to rebuild the file system.

Resizing BTRFS won't work if your issue is with the underlying RAID (mdadm).  It looks like RAID expansion simply didn't happen with two of the disks.   Also I believe you also need to specify the device ID of the RAID group in the resize command, as shown here: https://btrfs.wiki.kernel.org/index.php/UseCases#Resize_on_multi_devices_filesystem

One approach is to try to expand the mdadm RAID group manually, and then resize the file system.

Another is to remove one of the disks that isn't in the RAID group, and zero it (or unformat it) in a PC.  Then hot-insert it into the NAS, which should try to resync it again.  If it hasn't expanded when the resync completes, then reboot the NAS and see if that works.  If you are successful, then you can repeat this process with the remaining disk.

But either way, this won't address the errors you are getting with the balance.

[xcntalien2]

Thanks for your response. Which log(s) should I look t to ascertain the reason for the balance failure? I did have a look at some of them but coun't find anything related. I will look again at the command line for mdadm / BTRFS and the zero-ize a disk option.

[StephenB]

I'd look for BTRFS errors in system.log and kernel.log.

You could also run the balance from ssh.  Look into the command line options though, as the default parameter values could take a very long time to run.

[mdgm]

smart_history.log shows changes in key SMART values. ATA errors aren’t the only thing to track.

[StephenB]

---

@mdgm wrote:

ATA errors aren’t the only thing to track.

I totally agree.  Personally I find the Pending sector and Reallocated sector counts to be the most important indicators.  Unrecoverable errors, command timeouts and spin-up problems are also useful.  Many of the other SMART stats don't correlate to disk failures.