2tb disks showing wrong capacity.

A1R2N3A4K5

Hi,

I have a NAS 320 as network storage. Running under windows 10.

Having changed from 2 x 1gb in raid 1 to 2 x 2gb in raid 1.

Each disk is showing as 1,8tb but the total storage is only showing as 930bg

When I originally installed and expanded the disk the total volume showed the correct value, has anyone have any ideas on how to recover the lost space please?

Thanks,

Martin

Mijzelf

When I originally installed and expanded the disk the total volume showed the correct value

What do you mean by that? Installed is clear, but how did you originally expand the volume? Is that another case than your recent exchange of the disks?

A1R2N3A4K5

Hi,

Thanks fro replying.

I have 2 x 1tb disks installed at the start.

Removed 1 and installed a new 2tb disk.

Rebuilt the raid 1 volume then removed the 2nd 1tb disk and installed another new 2tb disk rebuilt and then used the expand function to be able to use the full amount of space.

As far as I recall the disks showed 2tb.

Now when I check on disk 1 and 2 they both read 1.8tb but the available space on the combined drive is only 980gb I'm at a loss to explain this so any help would be appreciated.

For the moment my plan is to remove 1 disk reformat it to 2tb using an external drive then rebuild the array then do the same with the other 2tb disk, rebuild the array, and expand.

Hopefully, that should work?

Thanks,

Martin

Mijzelf

Hopefully, that should work?

Probably not. If you remove the disk, and change it's partition layout on a remote system, the NAS will treat the reinserted disk as a new disk, and just repartition it. Just as it did before.

Enlarging of a raid1 array consists of 4 steps:

1. Enlarge both containing partitions.
2. Enlarge the raid container.
3. Enlarge the contained filesystem.

(Shrinking goes the same, but in reverse order)

I think step 1 was done when you added the disk. For the firmware it makes no sense to create a partition which doesn't span the disk. Step 2 and 3 have to be done after both disks were exchanged, and the firmware detects the raid container isn't as big as both containing partitions. Step 2 can hardly fail, it's just a number in the raid header(s). Step 3 is complicated. The filesystem is basically a database on the raw disk surface containing the files and their mutual consistency. You can't simply resize it, parts of the database logic have to be moved, and new, empty database entries have to be made. Before you start such an operation you have to be sure the database is internally consistent, which means you run a filesystem check, which has to succeed.

I think your filesystem is not 100% consistent, causing the resize to fail. Or better, the resize doesn't even start.

To find out in which step the box failed, you'll have to get shell access. On an NSA320 without 3rth party software the only way to get that is the Telnet backdoor. So open the backdoor, and login over telnet (on Windows you can use PuTTY for that), and execute

cat /proc/partitions
df -h

The first command shows the sizes of all block devices in units of 1kb. (Disks, partititions, raid arrays, …). The second shows the sizes of all mounted filesystems. I expect to see two partitions sda2 and sdb2 of both ~2TB in size, and a raid array md0 also ~2TB in size (but slightly smaller than the partitions), and a filesystem on /dev/md0 which is only 1TB. If that is the case, then the filesystem has to be repaired manually.

A1R2N3A4K5

Hi,

Thanks for the reply.

Update I removed a disk restarted the nas, stooped it re-inserted the 2nd disk, and am now trying a repair to see what happens.

Before I use the program you suggested I ran another scan as there doesn't appear to be a repair option for the 2 disks in raid 1

the result was this

Scan Result Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
No modify flag set skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set skipping filesystem flush and exiting.

Then I tried an expand and got this

Scan Result Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
No modify flag set skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set skipping filesystem flush and exiting.

I don't know if that helps but I will try the other program and see what is reports.

The firmware is 4.01 so it is well out of date, I have tried to update it but the file appears to no longer exist.

I have tried the backdoor program but it seems beyond my knowledge to get t to work.

Thanks,

Martin

A1R2N3A4K5

Hi Folks,

I have checked all over the net but can't find an answer so is there anyone out there who can advise me how to fix this problem, please?

Thanks,

Martin