Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use common progressbar function for cat and get #1779

Merged
merged 1 commit into from
Oct 11, 2015

Conversation

rht
Copy link
Contributor

@rht rht commented Oct 3, 2015

Where the progressbar wrapper is put before the stream is turned into tar.

@jbenet jbenet added the status/in-progress In progress label Oct 3, 2015
@jbenet
Copy link
Member

jbenet commented Oct 4, 2015

I think this needs rebase.


ctx cxt.Context
}

// NewWriter wraps given io.Writer.
func NewWriter(ctx cxt.Context, dag mdag.DAGService, archive bool, compression int, w io.Writer) (*Writer, error) {
func NewWriter(ctx cxt.Context, dag mdag.DAGService, archive bool, compression int, w io.Writer, progressBarOut io.Writer, size uint64) (*Writer, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is not the right way to do this. the prograss bar stuff does not belong here. All this stuff is already complicated, and this makes it way worse. there must be some way to report out the information from the Writer.

The simplicity and cleanliness of Interfaces really matters to their usability.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and their maintenance. I know the codebase is not great in this regard, but we should always strive to make it better. this progress bar stuff has no business inside unixfs/archive/tar/writer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about adding a channel telling the size being read to DAGService? Though a callback is more generic to allow outputting Object as in the requirement in #1778.

@jbenet
Copy link
Member

jbenet commented Oct 4, 2015

@rht let's walk through the problem again. is the issue that the progress cannot be estimated because the output is a tar archive, and tar adds a bunch of overhead? So the proposed solution here is to measure the bytes before they're tarred?


some other possible solutions:

  1. estimate the overhead, by counting the objects, estimating an upper bound based on the size of tar headers and possilbe zero padding, overshoot, and use that as a 100%.
    • we should be able to get within 10% of accuracy, so it's fine if 90%-100% is immediate in the progress bar.
    • this way, the interfaces remain unchanged, and the progress bar mess is kept contained
  2. (As you say) the writer could emit objects written in a sideband channel. this is similar however to just Tee-ing the (unarchived) writer, and using one output for the archive, and the other for the progress bar. This would be cleaner.
  • one possibility is to break apart the DagArchive writer.
  • I suspect (1) is way easier.
  • I suspect breaking apart the DagArchive into two functions (one to with Archives, one not) will make (2) easier.
  • ideally, all the progress bar stuff could happen entirely client-side, not on the daemon. Meaning, if we get the daemon to report total size, or even report progress updates at given intervals, the actual progress bar stuff can stay in the client side).

@rht
Copy link
Contributor Author

rht commented Oct 4, 2015

estimate the overhead, by counting the objects, estimating an upper bound based on the size of tar headers and possilbe zero padding, overshoot, and use that as a 100%.

Yes it is possible to do this accurately for tarred object, it's just that the entire dag has to be traversed.

On second thought, the progressbar should only report progress actually piped to the client (the tar.gz-ed stream) that it doesn't make sense to tell the pre-tar.gz stream.

@rht
Copy link
Contributor Author

rht commented Oct 4, 2015

(there is the client, and then there is the local node downloading stream from remote node...)

@jbenet
Copy link
Member

jbenet commented Oct 4, 2015

  • Yes it is possible to do this accurately for tarred object, it's just that the entire dag has to be traversed.

hmm yes. forgot dags don't include the total # of objects underneath. :/

@rht rht force-pushed the latest-progressbar branch from 2ee3b73 to a73a333 Compare October 4, 2015 15:17
@rht rht changed the title (WIP) Accurate get progressbar Use common progressbar function for cat and get Oct 4, 2015
@rht
Copy link
Contributor Author

rht commented Oct 4, 2015

Just removed the progressbar on dagreader.
Now this PR contains only a refactor.

@rht
Copy link
Contributor Author

rht commented Oct 4, 2015

Either:

  1. daemon reports to client its download progress via channel, which is not necessarily the stream piped to the client
  2. daemon knows the tar.gz / .gz file size before hand; progress count happens entirely client side.

@@ -159,8 +181,7 @@ func (gw *getWriter) writeArchive(r io.Reader, fpath string) error {
defer file.Close()

fmt.Fprintf(gw.Out, "Saving archive to %s\n", fpath)
bar, barR := progressBarForReader(gw.Err, r)
bar.Start()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should keep the Start with the Finish so it's symmetric calls. less error prone. think of these three lines like:

lk := sync.Lock{}
lk.Lock()
defer lk.Unlock()

@jbenet
Copy link
Member

jbenet commented Oct 4, 2015

👍 to the refactor. though:

  • keep the Start call symmetric to Finish (i.e. not hidden)

Sorry, something went wrong.

License: MIT
Signed-off-by: rht <rhtbot@gmail.com>
@rht rht force-pushed the latest-progressbar branch from a73a333 to 7caba7e Compare October 4, 2015 15:44
jbenet added a commit that referenced this pull request Oct 11, 2015
Use common progressbar function for cat and get
@jbenet jbenet merged commit bc0f0c2 into ipfs:master Oct 11, 2015
@jbenet jbenet removed the status/in-progress In progress label Oct 11, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants