NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
ReadyNAS 314 incorrect consumed storage reporting
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-volume-space/td-p/1067510
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 /dataYou can check if you deleted all the snapshots using this:
btrfs subvolume list -s /dataThis will also give more details
btrfs fi du -s /data/sharenameThis 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.
3 Replies
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 /dataYou can check if you deleted all the snapshots using this:
btrfs subvolume list -s /dataThis will also give more details
btrfs fi du -s /data/sharenameThis 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 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.
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
