Opened at 2008-03-24T22:20:12Z
Closed at 2008-03-25T18:56:14Z
#367 closed defect (fixed)
include SI's of files in logs?
Reported by: | zooko | Owned by: | warner |
---|---|---|---|
Priority: | major | Milestone: | 1.0.0 |
Component: | code-nodeadmin | Version: | 0.9.0 |
Keywords: | Cc: | ||
Launchpad Bug: |
Description
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:
- 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.
- 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:
- 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. ;-)
- Users of Tahoe are not gaining strong protection against traffic analysis, anyway, so SIs are not especially sensitive. Also, your logs are not public.
Change History (1)
comment:1 Changed at 2008-03-25T18:56:14Z by warner
- Resolution set to fixed
- Status changed from new to closed
Native upload (when clients speak directly to storage servers) now includes this message. The log message looks like this:
Clients which upload through a Helper will not emit this message on their own, however the helper will emit one on their behalf.
Not the easiest thing in the world to gather and work with, but it's a start..