* [9fans] patch/create problem (error?) @ 2008-09-12 7:34 Antonin Vecera 2008-09-12 7:54 ` Steve Simon 0 siblings, 1 reply; 9+ messages in thread From: Antonin Vecera @ 2008-09-12 7:34 UTC (permalink / raw) To: 9fans Hello all, I had problem to create a patch - the command didn't finish for long long time. I tried to do it manualy step by step from command line and it seems that the problem is with "cp" command. This is method how to repeat it: I have in my home dir prepared new version of tftpd.c ls -l $home/src/tftpd --rw-rw-r-- M 40 antonin antonin 7708 Sep 11 14:59 /usr/antonin/src/tftpd/tftpd.c 1. bind -b -c $home/src/tftpd /sys/src/cmd/ip 2. 9fs sources 3. cp /sys/src/cmd/ip/tftpd.c /n/sources/patch/tftpd-error ...and now it hangs. If I copy to /n/sources regular file, things go right. If I try to copy file from bind-ed dir, "cp" hangs. Maybe I am somewhere wrong, I am not sure. Antonin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] patch/create problem (error?) 2008-09-12 7:34 [9fans] patch/create problem (error?) Antonin Vecera @ 2008-09-12 7:54 ` Steve Simon 2008-09-12 8:34 ` Antonin Vecera 0 siblings, 1 reply; 9+ messages in thread From: Steve Simon @ 2008-09-12 7:54 UTC (permalink / raw) To: 9fans > I had problem to create a patch - the command didn't finish for long long time. I created a patch yesterday and it worked fine. It is fairly slow as it diff's all the files you have changed with those on sources. Sadly the 9p protocol is quite badly effected by high (intercontinential) RTTs. -Steve ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] patch/create problem (error?) 2008-09-12 7:54 ` Steve Simon @ 2008-09-12 8:34 ` Antonin Vecera 2008-09-12 11:47 ` erik quanstrom 0 siblings, 1 reply; 9+ messages in thread From: Antonin Vecera @ 2008-09-12 8:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Sep 12, 2008 at 9:54 AM, Steve Simon <steve@quintile.net> wrote: >> I had problem to create a patch - the command didn't finish for long long time. > > I created a patch yesterday and it worked fine. It is fairly slow as it > diff's all the files you have changed with those on sources. > > Sadly the 9p protocol is quite badly effected by high (intercontinential) RTTs. > > -Steve There were only 2 files in the patch. I wait for about 10 minutes and nothing. But then I tried to copy a file from command line. If I copied an ordinary file (to /n/sources) it was done immediately. But If I copied a file from bind-ed(!) directory it was endless... There was no diff, only copy file. Antonin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] patch/create problem (error?) 2008-09-12 8:34 ` Antonin Vecera @ 2008-09-12 11:47 ` erik quanstrom 2008-09-12 17:28 ` Antonin Vecera 2008-09-14 1:11 ` Dave Eckhardt 0 siblings, 2 replies; 9+ messages in thread From: erik quanstrom @ 2008-09-12 11:47 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 1556 bytes --] >>> I had problem to create a patch - the command didn't finish for long long time. >> >> I created a patch yesterday and it worked fine. It is fairly slow as it >> diff's all the files you have changed with those on sources. >> >> Sadly the 9p protocol is quite badly effected by high (intercontinential) RTTs. >> >> -Steve > > There were only 2 files in the patch. I wait for about 10 minutes and nothing. > But then I tried to copy a file from command line. > If I copied an ordinary file (to /n/sources) it was done immediately. > But If I copied a file from bind-ed(!) directory it was endless... > There was no diff, only copy file. i would guess the problem is a bit different. i'm assuming that reads from sources work fine. it's not until you try to write there that there's a problem. this sounds like a mtu problem. i have a similar problem. i am not able to submit patches over one particular network interface. however, if i use a lower mtu, things work fine. i believe this is because the dumpy dsl modem we have blocks icmp messages. you could lower the mtu on the interface, but rather than punishing all traffic, i wrote a program called cpmtu. cpmtu is attached. if you define this function fn cp {cpmtu -m 700 $*} before you run patch/create, i believe patch should work properly for you. as an aside: i don't think 9p itself limits plan 9 performance over high-latency links. the limitations have more to do with the number of outstanding messages, which is 1 in the mnt driver. - erik [-- Attachment #2: cpmtu.c --] [-- Type: text/plain, Size: 3190 bytes --] #include <u.h> #include <libc.h> int mtu = 8*1024; int failed; int gflag; int uflag; int xflag; void copy(char *from, char *to, int todir); int copy1(int fdf, int fdt, char *from, char *to); void usage(void) { fprint(2, "usage:\tcp [-gux] [-m mtu] fromfile tofile\n"); fprint(2, "\tcp [-x] [-m mtu] fromfile ... todir\n"); exits("usage"); } void main(int argc, char *argv[]) { Dir *dirb; int todir, i; ARGBEGIN { case 'g': gflag++; break; case 'u': uflag++; gflag++; break; case 'x': xflag++; break; case 'm': mtu = atoi(EARGF(usage())); if(mtu > 0) break; default: usage(); } ARGEND todir=0; if(argc < 2) usage(); dirb = dirstat(argv[argc-1]); if(dirb!=nil && (dirb->mode&DMDIR)) todir=1; if(argc>2 && !todir){ fprint(2, "cp: %s not a directory\n", argv[argc-1]); exits("bad usage"); } for(i=0; i<argc-1; i++) copy(argv[i], argv[argc-1], todir); if(failed) exits("errors"); exits(0); } int samefile(Dir *a, char *an, char *bn) { Dir *b; int ret; ret = 0; b=dirstat(bn); if(b != nil) if(b->qid.type==a->qid.type) if(b->qid.path==a->qid.path) if(b->qid.vers==a->qid.vers) if(b->dev==a->dev) if(b->type==a->type){ fprint(2, "cp: %s and %s are the same file\n", an, bn); ret = 1; } free(b); return ret; } void copy(char *from, char *to, int todir) { Dir *dirb, dirt; char name[256]; int fdf, fdt, mode; if(todir){ char *s, *elem; elem=s=from; while(*s++) if(s[-1]=='/') elem=s; sprint(name, "%s/%s", to, elem); to=name; } if((dirb=dirstat(from))==nil){ fprint(2,"cp: can't stat %s: %r\n", from); failed = 1; return; } mode = dirb->mode; if(mode&DMDIR){ fprint(2, "cp: %s is a directory\n", from); free(dirb); failed = 1; return; } if(samefile(dirb, from, to)){ free(dirb); failed = 1; return; } mode &= 0777; fdf=open(from, OREAD); if(fdf<0){ fprint(2, "cp: can't open %s: %r\n", from); free(dirb); failed = 1; return; } fdt=create(to, OWRITE, mode); if(fdt<0){ fprint(2, "cp: can't create %s: %r\n", to); close(fdf); free(dirb); failed = 1; return; } if(copy1(fdf, fdt, from, to)==0 && (xflag || gflag || uflag)){ nulldir(&dirt); if(xflag){ dirt.mtime = dirb->mtime; dirt.mode = dirb->mode; } if(uflag) dirt.uid = dirb->uid; if(gflag) dirt.gid = dirb->gid; if(dirfwstat(fdt, &dirt) < 0) fprint(2, "cp: warning: can't wstat %s: %r\n", to); } free(dirb); close(fdf); close(fdt); } int copy1(int fdf, int fdt, char *from, char *to) { char *buf; long n, n1, rcount; int rv; char err[ERRMAX]; buf = malloc(mtu); /* clear any residual error */ err[0] = '\0'; errstr(err, ERRMAX); rv = 0; for(rcount=0;; rcount++) { n = read(fdf, buf, mtu); if(n <= 0) break; n1 = write(fdt, buf, n); if(n1 != n) { fprint(2, "cp: error writing %s: %r\n", to); failed = 1; rv = -1; break; } } if(n < 0) { fprint(2, "cp: error reading %s: %r\n", from); failed = 1; rv = -1; } free(buf); return rv; } ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] patch/create problem (error?) 2008-09-12 11:47 ` erik quanstrom @ 2008-09-12 17:28 ` Antonin Vecera 2008-09-12 18:16 ` erik quanstrom 2008-09-14 1:11 ` Dave Eckhardt 1 sibling, 1 reply; 9+ messages in thread From: Antonin Vecera @ 2008-09-12 17:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Sep 12, 2008 at 1:47 PM, erik quanstrom <quanstro@quanstro.net> wrote: >>>> I had problem to create a patch - the command didn't finish for long long time. >>> >>> I created a patch yesterday and it worked fine. It is fairly slow as it >>> diff's all the files you have changed with those on sources. >>> >>> Sadly the 9p protocol is quite badly effected by high (intercontinential) RTTs. >>> >>> -Steve >> >> There were only 2 files in the patch. I wait for about 10 minutes and nothing. >> But then I tried to copy a file from command line. >> If I copied an ordinary file (to /n/sources) it was done immediately. >> But If I copied a file from bind-ed(!) directory it was endless... >> There was no diff, only copy file. > > i would guess the problem is a bit different. i'm assuming that > reads from sources work fine. it's not until you try to write there > that there's a problem. > > this sounds like a mtu problem. i have a similar problem. > i am not able to submit patches over one particular > network interface. however, if i use a lower mtu, things work fine. > i believe this is because the dumpy dsl modem we have > blocks icmp messages. > > you could lower the mtu on the interface, but rather than > punishing all traffic, i wrote a program called cpmtu. cpmtu > is attached. if you define this function > fn cp {cpmtu -m 700 $*} > before you run patch/create, i believe patch should work > properly for you. > > as an aside: i don't think 9p itself limits plan 9 performance > over high-latency links. the limitations have more to do with > the number of outstanding messages, which is 1 in the mnt > driver. > > - erik > It seems you are right. I think I used in my previous tests too specific (small) files. I will try to play with mtu and with your "cpmtu". Anyway, does 9P and Plan9 know about "path MTU discovery"? Or have I something wrong at my firewall/router? Other of my computers (FreeBSD,Windows) don't have such problems. Antonin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] patch/create problem (error?) 2008-09-12 17:28 ` Antonin Vecera @ 2008-09-12 18:16 ` erik quanstrom 2008-09-13 19:14 ` Antonin Vecera 0 siblings, 1 reply; 9+ messages in thread From: erik quanstrom @ 2008-09-12 18:16 UTC (permalink / raw) To: 9fans > Anyway, does 9P and Plan9 know about "path MTU discovery"? traditional path mtu uses icmp messages. if your router/modem/whatever eats icmp, you're outta luck with these traditional methods. cf. http://www.netheaven.com/pmtu.html i think there are some tricks to get around the missing icmp messages, though. > Or have I something wrong at my firewall/router? > Other of my computers (FreeBSD,Windows) don't have such problems. have you tried mounting sources from these machines? i think this problem is pecular to sources. if the pmtu is symmetric, it seems sources is a few bytes short of a full packet. 1510 bytes. yet when i read from a local machine, the tcp packets are a bit long of a full packet -- 1518 bytes. something to look into. - erik ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] patch/create problem (error?) 2008-09-12 18:16 ` erik quanstrom @ 2008-09-13 19:14 ` Antonin Vecera 0 siblings, 0 replies; 9+ messages in thread From: Antonin Vecera @ 2008-09-13 19:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Sep 12, 2008 at 8:16 PM, erik quanstrom <quanstro@quanstro.net> wrote: >> Anyway, does 9P and Plan9 know about "path MTU discovery"? > > traditional path mtu uses icmp messages. if your router/modem/whatever > eats icmp, you're outta luck with these traditional methods. > cf. http://www.netheaven.com/pmtu.html i think there are some tricks > to get around the missing icmp messages, though. > >> Or have I something wrong at my firewall/router? >> Other of my computers (FreeBSD,Windows) don't have such problems. > > have you tried mounting sources from these machines? > > i think this problem is pecular to sources. if the pmtu is > symmetric, it seems sources is a few bytes short of a full packet. > 1510 bytes. yet when i read from a local machine, the tcp > packets are a bit long of a full packet -- 1518 bytes. > > something to look into. > > - erik I solved it. The source of this problem was an old NAT program on my router. Thanks Erik, you show me where to look for it. Antonin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] patch/create problem (error?) 2008-09-12 11:47 ` erik quanstrom 2008-09-12 17:28 ` Antonin Vecera @ 2008-09-14 1:11 ` Dave Eckhardt 2008-09-14 1:45 ` erik quanstrom 1 sibling, 1 reply; 9+ messages in thread From: Dave Eckhardt @ 2008-09-14 1:11 UTC (permalink / raw) To: 9fans > fn cp {cpmtu -m 700 $*} How about dd? Dave Eckhardt ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] patch/create problem (error?) 2008-09-14 1:11 ` Dave Eckhardt @ 2008-09-14 1:45 ` erik quanstrom 0 siblings, 0 replies; 9+ messages in thread From: erik quanstrom @ 2008-09-14 1:45 UTC (permalink / raw) To: 9fans On Sat Sep 13 21:13:15 EDT 2008, davide+p9@cs.cmu.edu wrote: > > fn cp {cpmtu -m 700 $*} > > How about dd? > > Dave Eckhardt > dd behaves differently from cp, and patch/create uses cp. in particular cp tries to copy the mode bits along. i thought it would be easier to be correct in adding 4 lines to cp than writing a shim than makes dd work like cp. especially since cpmtu had already been written. i could be wrong, but that's what i was thinking. by the way, my method is completely bogus and accidentally works most of the time. that should be obvious from the fact that i'm using an mtu of 700 rather than 1500 or even 1510. tcp, being a stream protcol, doesn't respect write boundaries. so even if the 9p messages are small enough, tcp helpfully packs them together. (unfortunately changing the mtu on a running interface hung the interface. i don't know if this behavior persists.) 9p2000 mostly hides the stream nature of tcp, but once in a while it rears its head. - erik ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-09-14 1:45 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-09-12 7:34 [9fans] patch/create problem (error?) Antonin Vecera 2008-09-12 7:54 ` Steve Simon 2008-09-12 8:34 ` Antonin Vecera 2008-09-12 11:47 ` erik quanstrom 2008-09-12 17:28 ` Antonin Vecera 2008-09-12 18:16 ` erik quanstrom 2008-09-13 19:14 ` Antonin Vecera 2008-09-14 1:11 ` Dave Eckhardt 2008-09-14 1:45 ` erik quanstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).