Greg: would you be so kind as to open an issue ticket for this? Your suggestions about how to improve the UI sounded spot on.
Sure, and I filed into the easy bits and the hard bit separately: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1221 http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1222 Regarding: Whatever you do, don't fix linuxpal! We need linuxpal to keep misbehaving so that we can understand how to fix the clients to ignore misbehaving servers like that. ;-) I have two theories: A) I ran 'find . -size +8192 | xargs rm' in the storage area on some nodes to reclaim space so I could repair 1 KB files. I don't think I did this on linuxpal, as it still has lots free, and I think the ones I did it on are fine, but the theory is that this causes DYHB to say yes from some db and then choke when asked for it. I don't really believe this theory. B) There is some firewall impairment. Evidence for this theory is that if I stop my client and then restart it, then a deep check fails on servers-of-happiness issues promptly, and I get responses in a reasonable time from sunpal7 and linuxpal. I'm looking at netstat on both ends, but I wonder if tahoe has any keepalives/makedeads in the connections to servers. There are a ton of broken firewalls out there and having a ping to each server every few minutes might help (esp if that is scoreboarded too and ping failures are logged and cause teardown/reinit of the connection).
pgpN27oayvXAz.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
