[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2823: "tahoe cp FILE ALIAS:" does unnecessary directory reads
Tahoe-LAFS
trac at tahoe-lafs.org
Sat Sep 3 22:11:48 UTC 2016
#2823: "tahoe cp FILE ALIAS:" does unnecessary directory reads
----------------------------------+---------------------------
Reporter: warner | Owner:
Type: defect | Status: new
Priority: normal | Milestone: undecided
Component: code-frontend-cli | Version: 1.11.0
Keywords: performance tahoe-cp | Launchpad Bug:
----------------------------------+---------------------------
I noticed that running `tahoe cp FILE my:` (where `my:` is an alias
pointing at a directory with about 20 subdirectories) performs 20
directory reads before finally doing the expected upload and read+write
assignment to the top-level directory. The CLI frontend is doing 20
separate WAPI `GET /uri/CAP?t=json` for each subdirectory.
It looks like targetting `ALIAS:` (rather than a fully-qualified
`ALIAS:FILE`) is putting tahoe-cp in a mode where it finishes with a WAPI
`POST /uri/ALIAS?t=set_children`. To do that, it wants to have the full
contents of the target directory. However I think it should be able to get
that information from the initial GET, rather than needing to fetch the
contents of each subdirectory.
I don't remember why we're using `set_children` anyways. But I do remember
an extensive investigation into how tahoe-cp ought to behave when the
target is a directory (e.g. `tahoe cp DIR ALIAS:` or `tahoe cp DIR
ALIAS:SUBDIR`). There might be a way to simplify this by transforming
`tahoe cp X ALIAS:` into `tahoe cp X ALIAS:X`. Or at least an argument
that the two ought to behave the same way.
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2823>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list