How to cCheck Size of a share/folder?

This is not possible in the current firmware.

We will certainly consider if there is a way to implement this in a future release.

Thanks for the response.
Seems a bit strange that the field is there is the list view when it will never be populated in the current firmware version.

Do i need to post this request in the feature request section?

It's been requested before, so I don't think you need to post it again. Though you can if you like of course.

This sounds simple, but with btrfs file systems it actually isn't. With CoW, data blocks are shared between multiple folders. The way the NAS is structured that is limited to folders and their snapshots, but the file system isn't limited to only that structure. So even defining what the folder size means isn't that simple for btrfs generally.

For the normal OS6 share structure, the feature can be provided, but it relies on the btrfs quota package - last time I heard that was still viewed as experimental. Hopefully Netgear will add it as soon as it is fully stable.

Interesting insight

Bumping this old thread just to indicate that there is still interest in having some sort of indicator, even if not very accurate. While I understand StephenB explanation, clearly there is a way to implement simple bar style indicator, as proved by the fact that it was done for full volume, and shows very nicely "data" -- as a bar, pie chart or numeric values. I am not certain why it was possible to do it for full volume, yet it is supposedly so difficult to have similar indicators next to each share/folder. This is pretty basic functionality - and is still sadly missing.

Hephaestus wrote:
I am not certain why it was possible to do it for full volume, yet it is supposedly so difficult to have similar indicators next to each share/folder. This is pretty basic functionality - and is still sadly missing.

It's simple for the entire volume because the file system does know how many data blocks are used in total. Without the quota feature I mentioned above, btrfs doesn't have an easy way to track how many data blocks are uniquely used in each folder when snapshots are enabled.

Some of the other proposed features (in particular using --reflink by default when moving files between shares) make this problem more complicated, since it extends CoW across share boundaries. That is, moving a file that way will result in the data blocks being shared between the new share, the new share's snapshots and the old share's snapshots.

I also want the feature (along with some better tools to manage snapshots generally). But there are cases where such indicators will be confusing - for instance when CoW is extended across shares, the sum of the space used in each share won't add up to the total space used in the volume.

Yes, of course, I forgot that this is btrfs... a bit embarassing, really. Thanks for clarifying!

Something still does not add up (pun intended). If the explanation given reflects the mechanism correctly, it should also be impossible (or: not that easy) to show size of a single file. Yet under "browse" sizes of all single files are listed. Regardless of btrfs mechanism I fail to see why one can have, say, 20 files in a folder, each one showing, say 1GB size... yet supposedly there is no easy way to show the folder size being in total 20GB. Just calculate from the bottom up, add, rather straightforward I would say.

Yes, I am aware that interpratation of what the folder really is and how the data blocks are distributed is not easy, but for the purpose of showing how much space on the disk is consumed by a folder this is irrelevant. It becomes a bit mystical if we copy 100GB of data to NAS, to physicall disks, and from now on we are unable to say how much of this physical disk the data (and snapshots, if enabled) consume.

Each file size includes shared and unshared data blocks. To get the actual disk usage for the share you can't double-count (or triple count) the shared blocks.

Avoiding the multiple-counting for the shared blocks is the problem.

Hypothetically, if a file system consisted of one file only, the file being 1GB, this file consumes 1GB of physical disk space.
If a file system consists of more files (usually the case), the same file does not consume 1GB of physical disk space (shared blocks).

Thus "size of a single file" really means: the size when the file is copied outside of ReadyNAS OS environment. Adding all files sizes within a folder, and showing the result as folder/share size would simply follow already adopted logic: this is the size of the folder when it is copied outside of ReadyNAS OS environment. Showing size of files and not showing the size of folders is logically inconsistent.