ReadyNAS 314 incorrect consumed storage reporting

[whetsel]

I have been moving some large files around and have tried running a balance but something is incorrect about my storage reporting in FrontView.

I have a ReadyNAS 314 running the latest firmware (6.10.8) with four 6TB drives installed in XRAID (Raid 5). In FrontView I show 15.58 consumed of 16.36 which is not correct, and I can't figure out why. I have logged in via SSH and ran du -sh * with the following output:

root@NAS:/# du -sh *
4.0K 1
372M apps
7.0M bin
0 boot
13T data
4.0K dev
12M etc
30M frontview
0 ftp_ban.tbl
4.0K header
34M lib
3.6M lib32
4.0K lib64
8.3T media
0 mnt
4.7M opt
4.0K php
du: cannot access 'proc/21483/task/21483/fd/3': No such file or directory
du: cannot access 'proc/21483/task/21483/fdinfo/3': No such file or directory
du: cannot access 'proc/21483/fd/3': No such file or directory
du: cannot access 'proc/21483/fdinfo/3': No such file or directory
0 proc
5.2M root
4.3M run
12M sbin
0 selinux
0 srv
0 sys
0 tmp
1.2G usr
644M var

My /data folder is only 13TB (/media being two 5TB USB drives with data on them). So where is my missing over 2TB of space?

I have deleted all of the snapshots, ran the touch command and reboot so see if that free things up.

touch /.force_snapshots_upgrade
systemctl restart readynasd

I am currently running a manual balance to see if that helps since the balance in FrontView didnt seem to do anything.

btrfs balance start -dusage=55 /data 

I may also try: (not sure /mnt is the correct location to run this against)

btrfs balance start /mnt

If this doesn't work, what the heck are my next steps? Just trying to get ahead of the curve here... I noticed it was a problem when I thought I had nearly 3TB of free space and logged in only to find 1GB of free space causing other issues.

Link where I got these commands: https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/Inaccurate-reporting-of-used-free-v... 

[StephenB · Accepted solution]

---

@whetsel wrote:

I may also try: (not sure /mnt is the correct location to run this against)

btrfs balance start /mnt

---

It's not.  Normally mount is an empty folder in root. 

No idea why the command did something to the data volume on @Sandshark's system back in 2016. 

---

@whetsel wrote:

If this doesn't work, what the heck are my next steps?

---

Obviously it would be prudent to have an up-to-date back up of the data.

You should be using btrfs commands for your troubleshooting - the usual linux commands do not give the right answers for btrfs.

btrfs fi show /data
btrfs fi df /data

You can check if you deleted all the snapshots using this:

btrfs subvolume list -s /data

This will also give more details

btrfs fi du -s /data/sharename

This last command can take a long time to complete. You can leave off the -s, but you will get a lot of output.

Note also you can use it (with or without the -s) on subfolders of the share, or even individual files.

[StephenB · Accepted solution]

---

@whetsel wrote:

I may also try: (not sure /mnt is the correct location to run this against)

btrfs balance start /mnt

---

It's not.  Normally mount is an empty folder in root. 

No idea why the command did something to the data volume on @Sandshark's system back in 2016. 

---

@whetsel wrote:

If this doesn't work, what the heck are my next steps?

---

Obviously it would be prudent to have an up-to-date back up of the data.

You should be using btrfs commands for your troubleshooting - the usual linux commands do not give the right answers for btrfs.

btrfs fi show /data
btrfs fi df /data

You can check if you deleted all the snapshots using this:

btrfs subvolume list -s /data

This will also give more details

btrfs fi du -s /data/sharename

This last command can take a long time to complete. You can leave off the -s, but you will get a lot of output.

Note also you can use it (with or without the -s) on subfolders of the share, or even individual files.

[whetsel]

@StephenB thanks for the replies.

I ran the btrfs commands you wrote out sans the one the last one, here were the results: 

root@NAS:~# btrfs fi show /data
Label: '2fe61160:data'  uuid: c85f4904-6807-44ea-9295-dffc33cd23be
        Total devices 1 FS bytes used 13.85TiB
        devid    1 size 16.36TiB used 16.02TiB path /dev/md127

root@NAS:~# btrfs fi df /data
Data, single: total=15.98TiB, used=13.84TiB
System, DUP: total=32.00MiB, used=2.25MiB
Metadata, DUP: total=15.50GiB, used=11.62GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
root@NAS:~# btrfs subvolume list -s /data
root@NAS:~#

The balance I started last night via SSH is still running this morning, but I am happy to report that having just log into FrontView it is now reporting correctly. I rushed the post last night in concern, but it appears a balance indeed fixes things. Not sure why the GUI balance did not vs the one I ran from SSH is working. 

PS. Thanks for confirming that /mnt was the wrong location for the "full balance". I could not for the life of me think how that helped them, I was going to run it against /data but won't now.

[StephenB]

---

@whetsel wrote:

The balance I started last night via SSH is still running this morning, but I am happy to report that having just log into FrontView it is now reporting correctly. I rushed the post last night in concern, but it appears a balance indeed fixes things. Not sure why the GUI balance did not vs the one I ran from SSH is working. 

There a balancing between speed of the balance and the amount of space reclaimed.

The GUI was probably using a higher threshold for -dusage, which wouldn't compact as many blocks.

You could try running balance a couple of times with successively smaller -dusage values - it likely will free up a bit more space.  Best not to go to -dusage=0 in one step - that can take a very long time, and might also run out of working space for the compaction.  Lowering it gradually usually results in each step completing quickly.