[tahoe-dev] symlink to storage on a different drive and available space reporting
david at triendl.name
Tue Jan 26 17:24:12 UTC 2010
On Tue, Jan 26, 2010 at 09:34:00AM -0700, Jody Harris wrote:
> So, we have several users who are storing the Tahoe shares on a drive other
> than where /home is located.
I have a similar strategy, placing the node data in /var/lib/tahoe and the
shares on a drive mounted at /srv/gridname, and I don't have any problem:
david at mimir:/var/lib/tahoe/testgrid$ ls -l storage
lrwxrwxrwx 1 root root 20 Jan 16 18:18 storage -> /srv/tahoe/testgrid/
david at mimir:/var/lib/tahoe/testgrid$ df -h . storage
Filesystem Size Used Avail Use% Mounted on
14G 2.0G 12G 16% /
2.0G 699M 1.4G 35% /srv/tahoe/testgrid
david at mimir:/var/lib/tahoe/testgrid$ wget -O - -q http://mimir:3567/storage | grep -A 1 "free (r"
<tr><td>Disk space free (root):</td>
As you can see, the only difference is, that I link storage/ to a different
location, while you link storage/shares. A look at the code
(src/allmydata/storage/server.py) confirms it: There are two directories, one
called the "storedir" (storage/), which the statvfs-call is called for, and the
"sharedir" (storage/shares) which holds the actual shares.
As you can see, the fix is easy: (src/allmydata/storage/server.py, around line
151) replace "disk_avail = self.stat_disk(self.storedir)" with "disk_avail =
self.stat_disk(self.sharedir)", or change the symlink to link storage/ instead
> Our strategy at this point is to simply delete the .tahoe/storage/shares
> directory and create a symlink to the desired storage location.
> This results in the available space reported as something completely
> unrelated to reality.
> Obviously, this is the wrong strategy. What does the tahoe-dev team
> - Think carefully.
> - Contra mundum - "Against the world" (St. Athanasius)
> - Credo ut intelliga - "I believe that I may know" (St. Augustin of Hippo)
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
More information about the tahoe-dev