Datastore usage

[Quickly]

Hello.
I have various datastores. Can I read via GUI or CLI which datastore uses how much space effectively?
Unfortunately I can only see the total usage in the GUI.

Would be very cool if you could see this as a list in the GUI. Or am I too blind?

THX, Lars

 

[dcsapak]

if the datastores are on different file systems, you see that info in the dashboard

if they share the filesystem, gathering the real usage info would be very costly (going through all files and counting) so we do not do that

if you want to do it yourself, you can do it like this:

du -sh /path/to/datastore

but be aware that this can take a while, and will generate a bit of load on the storage, since it has to go through all files and count their sizes...

 

[ryanatuniserve]

Would it be possible for the size of a datastore to just be stored each time data is added as a static value?

I notice there are some .blob files that appear to be metadata of some sort under a given datastore, for example:
/mount1/datastoretest/vm/100/<date>

-rw-r--r-- 1 backup backup    794 Jul 13 16:10 client.log.blob
-rw-r--r-- 1 backup backup 266240 Jul 13 16:10 drive-scsi0.img.fidx
-rw-r--r-- 1 backup backup    400 Jul 13 16:10 index.json.blob
-rw-r--r-- 1 backup backup    357 Jul 13 16:09 qemu-server.conf.blob

The actual data would be under /mount1/datastoretest/.chunks

The dashboard keeps track of things such as deduplication factor, would it be possible for the size of backups to just be appended to a metadata file above? Each iterative backup after would just do some basic math and see what differs? Or, does the deduplication itself make that a bit of a difficult endeavor?

Thanks for the great software, both VE and Backup Server are splendid

 

[dcsapak]

Would it be possible for the size of a datastore to just be stored each time data is added as a static value?

this would probably bad for perfomance when doing many backups/garbage-collects in parallel since that updating would have to behind a lock which every backup needs then...
so either only one backup could run at a time, or every backup must lock/unlock that permanently...

The dashboard keeps track of things such as deduplication factor,

actually that is only the information from the last garbage collection, as soon as you add/remove a backup, it is wrong again, but we save it since that makes sense to show
but the filesystem usage would be too misleading, as someone might use that as a 'monitoring' for the usage. (but if e.g. a gc is run only weekly, that data is out of date for a whole week!)