id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
367	include SI's of files in logs?	zooko	warner	"I think it would be good to include information about files added, linked, and unlinked, in the logs, including the file's storage index (""SI"").

This might help analyze behavior after the fact.

Brian is uncomfortable with this idea.  I think that his objections are two-fold:

1.  Parsing logs is an error-prone way to infer filesystem structure.  There are better ways to track the evolution of filesystem structure that we want to implement eventually: manifests and/or deep-verify capabilities.  Also, people can already share their read-capabilities with us so that we can examine their filesystem directly.

2.  If you want to share your logs with someone else, so that they can debug, then including SI's in logs exposes to them more information about the structure (but not the content) of your filesystem.

My counter-arguments to Brian's objections are:

1.  Putting SIs in logs makes the logs more informative than deep-verify caps or sharing your read-caps -- it includes information about the timing and related-event to filesystem changes.

1.b.  Putting SIs in logs doesn't require us to parse those logs and infer filesystem structure -- it is useful for simpler, flatter, lossier kinds of monitoring, too.

1.c.  Putting SIs in logs doesn't preclude us from implementing something good like deep verify caps -- it is too lossy to succeed at that.  ;-)

2.  Users of Tahoe are not gaining strong protection against traffic analysis, anyway, so SIs are not especially sensitive.  Also, your logs are not public.



"	defect	closed	major	1.0.0	code-nodeadmin	0.9.0	fixed