tahoe-lafs/trac-2024-07-25

add webapi for quota-usage measurement #370

New issue

Closed

opened 2008-03-27 18:06:55 +00:00 by warner · 3 comments

warner commented

2008-03-27 18:06:55 +00:00

Owner

This number is awfully rough: directories cost zero bytes, mutable files are ignored, and neither expansion nor encoding/ext3 overhead is taken into account. Also, this number is purely voluntary. The accounting/quota work in #119 is the mandatory side: measuring usage on the server side and correlating it between all servers.

The code for this will be written on top of the manifest-generating code, and will extract the filesize from the verifycaps of each immutable file in the manifest.

I'm thinking that the webapi for this will be:

GET http://uri/$URI?t=total-size

but maybe it ought to be a POST instead, to discourage robots from triggering a bazillion directory fetches.

We could use a web interface that takes a directory read-cap and traverses it, computing the sum of the sizes of all immutable files reachable from that directory. This number is a rough measurement of the storage used. For our consumer product, this number will be presented in the "you are using X out of Y bytes" box on the user's account page. This number is awfully rough: directories cost zero bytes, mutable files are ignored, and neither expansion nor encoding/ext3 overhead is taken into account. Also, this number is purely voluntary. The accounting/quota work in #119 is the mandatory side: measuring usage on the server side and correlating it between all servers. The code for this will be written on top of the manifest-generating code, and will extract the filesize from the verifycaps of each immutable file in the manifest. I'm thinking that the webapi for this will be: GET <http://uri/$URI?t=total-size> but maybe it ought to be a POST instead, to discourage robots from triggering a bazillion directory fetches.