Opened at 2008-01-30T17:06:01Z
Closed at 2008-02-06T02:31:39Z
#292 closed task (fixed)
display current local node size on Welcome page
Reported by: | terrell | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 0.8.0 (Allmydata 3.0 Beta) |
Component: | code-frontend-web | Version: | 0.7.0 |
Keywords: | Cc: | ||
Launchpad Bug: |
Description
I checked my node connected to the TestGrid and found 59M. While not totally a surprise, I would like to see that reported (tracked over time?) on the Welcome page of my node.
Overview/Dashboard? data is always good to make visible.
[~/.tahoe] du -h | tail -1 59M .
Change History (2)
comment:1 Changed at 2008-01-31T01:55:48Z by warner
- Keywords helper removed
- Milestone changed from 0.8.0 (Allmydata 3.0 Beta) to undecided
comment:2 Changed at 2008-02-06T02:31:39Z by warner
- Milestone changed from undecided to 0.8.0 (Allmydata 3.0 Beta)
- Resolution set to fixed
- Status changed from new to closed
I've added this display, in 27f46f2aaf5479b0. The code uses StorageServer.allocated_size(), which combines how much space is currently used on disk with the space that has been allocated (but not yet filled) by incoming allocate-share requests. The display is just raw bytes right now, so it's kind of ugly. I'd be happy to accept a patch that formats is slightly better, the code is in src/allmydata/webish.py Root:data_storage(), around line 1319.
Funny, at first I thought you mean RAM footprint, and I was thinking "59M, wow, that's kind of big". Then I noticed that you're talking about disk footprint, and I thought "59M, wow, that's really small" :-).
I assume that you didn't set sizelimit to '0', since we haven't really made it easy or obvious to do that, so you're probably picking up shares from everyone else who connects to the test grid. If you poke inside your node's basedir, you ought to find that almost all of that 59MB is coming from the storage/shares/ directory.
The only immediate concern I'd have with implementing this display is that the 'du' command will take a long time to run once the storage directory gets very large, so I'd be nervous about running it all the time. (also, there are cross-platform compatibilty issues to resolve). On the other hand, the storage server class tries to keep track of how much space is being consumed, updated incrementally, so it would probably be relatively cheap to display that value on the welcome page. The remaining question is how to cleanly get the data from the storage server to the web server.. we probably need some internal cleanup for that.