This is a bit strange. Maybe if you filled up the metadata on the first 2 layers (create a new share with lots of small files) then some metadata will have to be allocated on RAID layer 3 that might change things.
Metadata contains data about data. Some of this is fixed per file no matter whether your file is 1KB or 1TB which is why adding lots of small files is best.
I wonder if metadata needs to be allocated on a layer for it to be used for iSCSI LUNs.
I would make sure your backup is up to date before trying that.
Somehow this data is not allocated to the Data Volume and is not available for use
I think you are misunderstanding what allocated/unallocated means.
Free space is a somewhat slippery concept with the BTRFS file system.
BTRFS allocates space for your data (i.e. your LUNS) and metatdata in "chunks". If a chunk is only partially filled with data, there is free space in the chunk - but it is wasted. If a chunk holds no data, it is entirely free space, and not allocated. FWIW, this wasted space can be reclaimed by running a balance (which will consolidate used space, reducing the amount of unused space in the allocated chunks).
So your screen shot says that the full size of your data volume is 426.37 TiB (297.97+128.40). This breaks down into
297.97 TiB Used space (actually used by files - in this case LUNs)
~0 Allocated-Used of "wasted" free space, that isn't actually available for use.
128.40 TiB Unallocated free space that can be used for new LUNs or shares.
I am a bit puzzled on why the metadata total doesn't add up. That is, the three groups have 6.08 GB of allocated space for metadata between them, but the total allocation is reported as 3.04 GB. Not sure that is worth chasing down, but you could take a look with ssh if you want to try.
I may be misunderstanding what allocated/unallocted means
Attached screen shot, from Admin System, overview
Show data volume with 384.00 KB free of 297.08 TB
My previous screen show shows that my volume should be 426 TB (as you point out) however it is not, I only have 297 TB
My iSCSI LUN's are thick provisioned and only consume 280 TB of the 297 TB
Adding data to the iSCSI LUN's should not make less space on the SAN, as stated I am not using any other storage on the device,; however, I have slowly been consuming the 17 TB of free space on the SAN
To add to this, one of my iSCSI LUN's is now not available on the host server and my backups fail because they cannot write new files to the iSCSI LUN's
Seems like I am going to have to rebuild the array from scratch
I don't currently have a paid support contract, I was hoping Netgear would do incident support, but I guess I wll purchase a new contract to see if they can assist
BTW, my thinking here is that the RAID array itself is the proper size, but that the BTRFS file system somehow wasn't expanded to fill the full array.
Also, I've looked again at your numbers.
You are saying that your volume size is actually 279 TiB (300 TB). You are also saying that you started with 36x12 TB RAID60 (also using three RAID groups).
Three RAID6 groups results in 6 disks used for redundancy, so the volume size with 36x12TB should have been 360 TB (326 TiB). So even before expanding to 45x12TB the file system was too small.
However, 36x10TB would have yielded a 300 TB (279 TiB) volume. Is it possible that the array originally was 36x10TB, and then expanded to 36x12TB? If so, it looks like that first expansion didn't complete correctly.
I agree that the RAID array is the correct size but the expansion did not occur at the file system
I started with 36 x 12 TB drive, RAID 60 in 3 RAID groups. 2 RAID groups had 15 drives and the 3rd had 6 drives
FWIW, you don't really need to use the RAID calculator. 2 disks in each group are for redundancy, so you can get the full size in TB by subtracting those out from the total. The OS partition on each disk (4 GB) is in the noise. The system reports drive size in TiB, and you can easily convert TB to TiB in google. For instance, enter "300 TB in TiB".
But I am a bit confused on your starting configuration which used unequal sized RAID groups. I don't think you can use RAID-0 to stripe across unequal groups (though you should be able to concatenate them, but that isn't actually RAID60). That might actually be part of the problem.
