00:04:46  * AvianFluquit (Read error: Connection reset by peer)
00:06:12  * AvianFlujoined
00:25:32  * daviddiasjoined
00:29:51  * daviddiasquit (Ping timeout: 245 seconds)
00:45:39  <nahamu>if someone gave you a signed URL, could you use that to mlogin onto a file?
01:00:17  * nfitchjoined
01:05:16  * nfitchquit (Ping timeout: 264 seconds)
01:10:00  <nahamu>(or at least mln it so that you could then mlogin onto your own copy)?
01:10:14  <nahamu>(other than the obvious download the whole thing then re-upload it)
01:25:25  * daviddiasjoined
01:30:16  * daviddiasquit (Ping timeout: 245 seconds)
01:37:07  * abraxasjoined
02:11:06  * abraxasquit (Remote host closed the connection)
02:46:14  * abraxasjoined
02:49:01  * nfitchjoined
02:53:43  * nfitchquit (Ping timeout: 260 seconds)
03:19:40  * notmattjoined
03:20:14  * daviddiasjoined
03:24:59  * daviddiasquit (Ping timeout: 260 seconds)
03:26:49  * notmattquit (Ping timeout: 246 seconds)
03:29:26  <isaacs>I'm seeing a lot of request timeouts with mputs
03:29:30  <isaacs>UploadTimeoutError: request took too long to send data at ClientRequest.onResponse (/home/node/npmanta/node_modules/manta/node_modules/restify/lib/clients/http_client.js:132:38) at ClientRequest.g (events.js:175:14) at ClientRequest.EventEmitter.emit (events.js:95:17) at HTTPParser.parserOnIncomingClient (http.js:1688:21) at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:121:23)
03:29:36  <isaacs> a ChleartextStream.socketOnData (http.js:1583:20) at CleartextStream.read [as _read] (tls.js:507:12) at CleartextStream.Readable.read (_stream_readable.js:320:10) at EncryptedStream.write [as _write] (tls.js:366:25) at doWrite (_stream_writable.js:221:10)
03:37:11  <isaacs>er, https://gist.github.com/isaacs/7867052
03:37:54  <tjfontaine>isaacs: you weren't streaming anything at that point?
03:38:11  <tjfontaine>I mean you started the request, but no data was flowing on that connection
03:38:15  <isaacs>tjfontaine: i was streaming a bunch of things
03:38:25  <tjfontaine>sure, you could have easily starved a single connection
03:39:12  <isaacs>tjfontaine: mroe context: https://gist.github.com/isaacs/7867068
03:39:31  * AvianFluquit (Ping timeout: 250 seconds)
03:39:34  <isaacs>what's weird is that it's working fine from another machine
03:39:35  <isaacs>but not this one
03:39:36  <isaacs>and they're both in us-esat
03:39:56  <tjfontaine>similar sized instances?
03:40:22  * AvianFlujoined
03:41:26  <isaacs>oh, i guess not. one is 16GB and the other is 2GB
03:41:33  <tjfontaine>right, io starvation
03:41:40  <tjfontaine>you're hitting the zfs throttle likely
03:42:08  <isaacs>oh, no, one is 16GB and the other is 8GB
03:42:10  <isaacs>not 2
03:42:30  <isaacs>i don't see how it would be io starvation, i'm only actually sending one file at a time
03:42:56  <tjfontaine>I just assumed you were doing parallel
03:43:30  <tjfontaine>is it at a common period, and at the same file each time?
03:44:23  <isaacs>oh, no, wait, it's doing 30 by default
03:44:24  <isaacs>nvm :)
03:44:38  <tjfontaine>heh
03:44:44  <isaacs>yah, dropped concurrency to 1, same result
03:47:21  * notmattjoined
03:49:50  * AvianFluquit (Read error: Connection reset by peer)
03:53:07  * AvianFlujoined
03:58:43  <isaacs>ugh, well, this sucks. resized up to 15GB rss to test if that was the problem. it isn't. now, i can't resize back down to 8GB
03:59:56  <isaacs>rss holding steady at 1.4GB
04:00:16  <isaacs>glad i'm not a "real" customer, or i'd be angrily calling support right now.
04:01:28  <tjfontaine>jeepers, you're at heap limit?
04:02:02  <tjfontaine>take a core, and see what you're holding, I'm hoping you're just hitting a slow writer problem
04:04:34  * AvianFluquit (Read error: Connection reset by peer)
04:04:56  <isaacs>nono, i'm nowhere near any kind of limit
04:05:02  <isaacs>RSS for the whole machine
04:05:13  <isaacs>that's like half a dozen different node processes, elastic search, etc.
04:05:27  <tjfontaine>oh
04:05:40  <isaacs>but there's no reason why this zone needs to be 15GB
04:05:45  <isaacs>even 8 was excessive
04:05:53  <tjfontaine>is there any pattern to where the stalls are happening?
04:05:57  <isaacs>nope
04:06:01  <isaacs>seems to have passed
04:06:04  <isaacs>now it's working fine
04:06:08  <isaacs>that's why i blamed manta :)
04:06:46  <tjfontaine>well, need to try and gather as much information as it was happening :)
04:07:11  <tjfontaine>could be yet another tls stall
04:07:18  * AvianFlujoined
04:07:37  <tjfontaine>I presume your client is 0.10?
04:09:58  <isaacs>yep
04:10:00  <isaacs>0.10.22
04:19:57  * AvianFluquit (Read error: Connection reset by peer)
04:20:00  * daviddiasjoined
04:22:42  * AvianFlujoined
04:24:26  * daviddiasquit (Ping timeout: 245 seconds)
04:35:29  * AvianFluquit (Read error: Connection reset by peer)
04:37:46  * nfitchjoined
04:42:21  * nfitchquit (Ping timeout: 252 seconds)
04:48:30  * AvianFlujoined
04:50:27  * AvianFluquit (Read error: Connection reset by peer)
04:59:02  * AvianFlujoined
05:03:41  <isaacs>soo... this is weird.
05:03:47  <isaacs>https://gist.github.com/isaacs/7867578
05:04:09  <isaacs>i'm doing client.put with mkdirs:true, and it's giving me a DirectoryNotExist error
05:05:42  * AvianFluquit (Read error: Connection reset by peer)
05:08:30  * AvianFlujoined
05:14:29  * daviddiasjoined
05:18:36  * daviddiasquit (Ping timeout: 245 seconds)
05:19:55  * AvianFluquit (Read error: Connection reset by peer)
05:20:32  * AvianFlujoined
05:35:00  * AvianFluquit (Read error: Connection reset by peer)
06:08:41  * daviddiasjoined
06:12:46  * daviddiasquit (Ping timeout: 245 seconds)
06:14:38  * daviddiasjoined
06:19:26  * daviddiasquit (Ping timeout: 245 seconds)
06:26:35  * nfitchjoined
06:31:15  * nfitchquit (Ping timeout: 252 seconds)
06:31:36  * AvianFlujoined
06:35:03  * AvianFluquit (Read error: Connection reset by peer)
06:54:06  * AvianFlujoined
07:05:29  * AvianFluquit (Read error: Connection reset by peer)
07:08:53  * daviddiasjoined
07:13:11  * daviddiasquit (Ping timeout: 245 seconds)
07:15:23  * daviddiasjoined
07:19:51  * daviddiasquit (Ping timeout: 245 seconds)
07:20:54  * daviddiasjoined
08:06:12  * mamashjoined
08:15:22  * nfitchjoined
08:19:54  * nfitchquit (Ping timeout: 265 seconds)
10:04:02  * nfitchjoined
10:08:38  * nfitchquit (Ping timeout: 264 seconds)
11:00:25  * abraxasquit (Remote host closed the connection)
11:01:43  * marselljoined
11:05:01  * notmattquit (Remote host closed the connection)
11:13:56  * mamashpart
11:18:44  * mamashjoined
11:52:55  * nfitchjoined
11:57:25  * nfitchquit (Ping timeout: 250 seconds)
12:22:34  * irajoined
13:23:24  * mjnjoined
13:23:26  * mjn_quit (Ping timeout: 246 seconds)
13:33:04  * mamashpart
13:36:10  * mamashjoined
13:41:35  * nfitchjoined
13:46:11  * nfitchquit (Ping timeout: 250 seconds)
14:20:12  * abraxasjoined
14:24:35  * abraxasquit (Ping timeout: 245 seconds)
14:59:16  * chorrelljoined
15:05:36  * notmattjoined
15:05:51  * utlemmingjoined
15:13:26  * notmattquit (Ping timeout: 264 seconds)
15:30:23  * nfitchjoined
15:35:11  * nfitchquit (Ping timeout: 272 seconds)
15:47:25  * paulfryzeljoined
16:08:55  * AvianFlujoined
16:21:01  * abraxasjoined
16:25:13  * abraxasquit (Ping timeout: 246 seconds)
16:29:43  * mcavagejoined
16:31:18  * fredkjoined
16:32:15  * fredkquit (Client Quit)
16:32:37  * fredkjoined
16:35:36  * nfitchjoined
16:36:26  * ryancnelsonjoined
16:52:18  * dap_joined
17:01:10  * AvianFlu_joined
17:02:42  * AvianFluquit (Read error: Operation timed out)
17:02:51  * AvianFlu_quit (Client Quit)
17:03:02  * AvianFlujoined
17:06:01  * notmattjoined
17:11:29  * daviddia_joined
17:12:21  * daviddiasquit (Ping timeout: 245 seconds)
17:22:35  <isaacs>dap_: yeah, i was dyslexicing 1.1.2 and 1.2.1
17:22:47  <isaacs>it worked on the old zone, but not on the new one, and i was thinking that it was the same manta version
17:22:55  <isaacs>now on 1.2.2 it works fine
17:23:05  <dap_>No prob… I think you and I were looking at it at exactly the same time
17:23:26  <isaacs>i wonder if that timeout thing i was seeing before was also a bug that's been fixed.
17:23:48  <isaacs>must've checked the version number a dozen times, too. stupid human brains.
17:23:50  <isaacs>:)
17:24:05  <dap_>indeed :)
17:29:25  <mcavage>stupid semver!
17:32:19  * ins0mniajoined
17:32:30  <nahamu>mcavage: if someone signs a URL, is there a way to use that to do an "mln" to save a copy to your own namespace or would you have to download and re-upload?
17:32:49  <mcavage>the latter
17:33:43  <nahamu>so we'll have to wait for the ACL stuff to be able to pass something to enable personB to mln a file under /personA/stor/
17:34:01  <mcavage>yep
17:34:02  <nahamu>(I'm mostly thinking about thoth at the moment.
17:34:18  <mcavage>sorry :\
17:34:37  <nahamu>no worries. just thinking of ways to make the kernel engineers lives easier
17:35:42  <bahamas10>any particular reason manta depends on the github#master version of restify? https://github.com/joyent/node-manta/blob/master/package.json#L31
17:35:48  <mcavage>you could: mln(/A/stor/foo, /A/public/foo), mln(/A/public/foo, /B/stor/foo), mrm(/A/public/foo)
17:36:38  <nahamu>mcavage: right, expose a public copy just long enough to let the second person make a copy, then remove the snaplink.
17:37:33  <mcavage>bahamas10: probably not now.
17:38:37  <mcavage>bahamas10: i'll make sure restify is out at whatever is latest and have node-manta lock to that on the next publiush.
17:49:22  * notmattquit (Remote host closed the connection)
17:58:57  * daviddiasjoined
18:00:41  * daviddia_quit (Ping timeout: 245 seconds)
18:05:35  * ryancnelsonquit (Quit: Leaving.)
18:07:17  * AvianFlu_joined
18:07:41  * AvianFluquit (Disconnected by services)
18:07:44  * AvianFlu_changed nick to AvianFlu
18:13:02  <bahamas10>great, thank you mcavage , this clears up https://github.com/bahamas10/node-manta-sync/issues/6
18:13:49  <mcavage>bahams10: ok, I'll do this today.
18:13:58  <mcavage>I'll comment on that ticket when it's done.
18:15:24  <bahamas10>mcavage: great thanks, i appreciate that
18:23:35  <mcavage>bahamas10: done
18:37:14  * notmattjoined
18:38:27  <bahamas10>mcavage: cool, thanks again. hopefully that user will think twice before working at a place that blocks git :p
18:38:48  <mcavage>yeah, i've seen that before. I just forgetting people do this stupid shit :)
18:54:06  * paulfryzelquit (Read error: Connection reset by peer)
18:54:46  * paulfryzeljoined
18:54:56  <nahamu>If npm could fall back to git over https, it would probably pass through stupid firewalls, but maybe not.
18:55:07  * nahamuis not suggesting modifying npm
19:42:28  * paulfryzelquit (Read error: Connection reset by peer)
19:42:52  * paulfryzeljoined
19:47:40  <bahamas10>does manta have any concept of snapshots like zfs? ideally i'd like to snapshot ~~/stor/foo@whatever
19:48:09  <tjfontaine>well, there's mln
19:48:15  <bahamas10>i'm thinking not, and the only way to do this would be non-atomically by creating snaplinks recursively in that dir... which could get expensive in number of operations
19:48:17  <tjfontaine>but it's a object absed system
19:48:27  <bahamas10>tjfontaine: right, that's what i'm noticing
19:48:49  <tjfontaine>so the heirarchy is real, but keys still need to be processed independently
19:50:26  <bahamas10>sounds good, i didn't think it would be directly possible (as it's an abstraction on ZFS)... do you know how snaplinks work for pricing?
19:50:44  <bahamas10>ie. if i have 1G file, snaplink it, is it now 2G of data used? or not until i overwrite either object
19:51:03  <mcavage>bahamas10: you only pay for # of bytes on disk
19:51:13  <mcavage>so you would pay for 1G in your question.
19:51:59  <mcavage>and no there's no way to snapshot a tree or directory atomically.
19:52:06  <bahamas10>but once i overwrite (mput over) either object, then it would become 1G + (size of new file) correct?
19:52:11  <mcavage>correct
19:52:19  <mcavage>you pay for total # of bytes on disk.
19:52:38  <bahamas10>mcavage: that's what i thought... i'm wondering if it's feasible to use snaplinks to try and artificially create what i want
19:52:43  <bahamas10>mcavage: ok perfect, that makes sense
19:53:27  <mcavage>the intent of snaplinks was to be an arbitrarily-flexible client-side versioning scheme - but if you need it for a whole tree at a time you'd have to do something yourself on top (and use manta more like a block store).
21:12:28  * nfitch1joined
21:12:29  * nfitchquit (Read error: Connection reset by peer)
22:03:34  * chorrellquit (Quit: My iMac has gone to sleep. ZZZzzz…)
22:20:52  * mamashpart
22:23:15  * abraxasjoined
22:24:34  * ghostbarjoined
22:28:45  * abraxasquit (Ping timeout: 272 seconds)
22:30:56  * chorrelljoined
22:53:48  * daviddiasquit (Remote host closed the connection)
22:55:44  * dap_quit (Quit: Leaving.)
22:59:17  * dap_joined
23:08:23  * ghostbarquit (Remote host closed the connection)
23:08:49  * ghostbarjoined
23:11:14  * utlemmingquit (Remote host closed the connection)
23:13:19  * ghostbarquit (Ping timeout: 246 seconds)
23:16:15  * utlemmingjoined
23:17:06  * ghostbarjoined
23:20:04  * ghostbar_joined
23:21:41  * ghostbarquit (Ping timeout: 248 seconds)
23:34:29  * AvianFluquit (Ping timeout: 248 seconds)
23:49:42  <isaacs>mcavage: oh, dude, check it out! http://ta-tld.com/
23:49:47  <isaacs>we can get man.ta finally
23:49:48  <tjfontaine>oh god
23:50:07  <mcavage>we need to buy that.
23:50:35  <tjfontaine>isaacs: you have too much spare time :P
23:50:42  <mcavage>although, clicking their stupid "buy" button gives a 404
23:51:24  <mcavage>isaacs: demerit
23:51:28  <mcavage>you just trolled the fuck out of me
23:51:30  <tjfontaine>hahah
23:52:03  <isaacs>Opan sauce lol!
23:52:32  <mcavage>i didn't even read. wow - you get kudos for the most elaborate troll evar
23:52:59  <isaacs>mcavage: check out the copy, dude.
23:53:13  <mcavage>yes, i did now
23:53:34  <mcavage>i didn't even read it. I clicked "buy"
23:53:34  <isaacs>We providethe Regitsry services to the ".ta" Tape Level Domaine Name and provide Thsi axclusive domanon tos regist Rraors and thuirs customers Worldwidee...!!!!
23:54:53  <isaacs>http://npm.im/crimer
23:54:57  <isaacs>^ super handy