[9fans] patch/create problem (error?)

[9fans] patch/create problem (error?)

[Antonin Vecera]

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

Re: [9fans] patch/create problem (error?)

[Steve Simon]

> 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

Re: [9fans] patch/create problem (error?)

[Antonin Vecera]

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

Re: [9fans] patch/create problem (error?)

[erik quanstrom]

[-- 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;
}

Re: [9fans] patch/create problem (error?)

[Antonin Vecera]

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

Re: [9fans] patch/create problem (error?)

[erik quanstrom]

> 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

Re: [9fans] patch/create problem (error?)

[Antonin Vecera]

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

Re: [9fans] patch/create problem (error?)

[Dave Eckhardt]

> fn cp {cpmtu -m 700 $*}

How about dd?

Dave Eckhardt

Re: [9fans] patch/create problem (error?)

[erik quanstrom]

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