[tahoe-dev] odd determination of unhealthy

[David-Sarah Hopwood]

Greg Troxel wrote:
> I did a 'tahoe --check --raw' on my main directory in the pubgrid, and
> got an odd report: the object is 'unhealthy', even though all 10 shares
> are present, plus two leftover shares of a previous version.  I would
> call that healthy with some stale bits in need of garbage collection,
> but maybe I don't get it.

The current checker is supposed to consider a file to be unhealthy if fewer
than N (in this case 10) shares are present on any servers. So I don't
understand why this file was considered unhealthy.

We want to change the health criterion to take into account share
distribution (http://tahoe-lafs.org/trac/tahoe-lafs/ticket/614). By that
criterion, this file should still be considered healthy, but only just
for the default parameters. (It has a happiness of 7, because the shares
are distributed between only 7 servers.)

> Another oddity is that running check on another client resulted in
> seeing very few shares.  Both clients have real IP addresses.  But, the
> one that saw only 4 shares is running (w/o storage) on a machine that
> also runs a storage node.

This seems to be because only 5 servers responded. The servers that did
respond, reported the same shares that they had in the first check.

Had the client just been started? In that case it might not have
connected to all available storage servers yet
(http://tahoe-lafs.org/trac/tahoe-lafs/ticket/719).

> Is it expected that one can run a client and a storage node on one machine
> at the same time without problems?

Yes, that's a common situation.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100816/8a41a44a/attachment.asc>