Re: [9fans] watch command

Re: [9fans] watch command

[YAMANASHI Takeshi]

> now that is cool. Could you beat on iostats to do similar things?

How do you want to beat iostats?  I'm not familiar with iostats...
Thanks.
-- 

Re: [9fans] watch command

[Ronald G. Minnich]

On Wed, 20 Apr 2005, YAMANASHI Takeshi wrote:

> How do you want to beat iostats?  I'm not familiar with iostats...

iostats is quite neat, I learned it from this list. man iostats ...

ron

Re: [9fans] watch command

[Ronald G. Minnich]

On Wed, 20 Apr 2005, YAMANASHI Takeshi wrote:

> How do you want to beat iostats?  I'm not familiar with iostats...

Check it out, it's very cool. man iostats. The people on this list clued 
me in to it.

ron

Re: [9fans] watch command

[YAMANASHI Takeshi]

> > How do you want to beat iostats?  I'm not familiar with iostats...
> Check it out, it's very cool. man iostats. The people on this list clued 
> me in to it.

Yeah.  I think I got your point.  It should be trivial to add an option to
iostats so that it posts /srv/iostatsctl and messages should appear there
whenever file metadata changes are occured.

One might even be as ambitious as adding another option to indicate iostats
of which files should be notified by proto(2) file.
-- 

Re: [9fans] watch command

[YAMANASHI Takeshi]

> But what about a file that the server can provide that provides info about
> metadata changes

This would solve the problem that the "real" file might be changed
bypassing the watch file server.

The implementation need to be careful about not letting give the
information of files under permission guarded directories, though.
-- 

Re: [9fans] watch command

[YAMANASHI Takeshi]

Anyway, it's here:
	% mk install
	% watchfs main.c

"cat /n/watch/ctl" will block until a change has been made
to /n/watch/data/main.c.

KNOWN BUGS:
	- it doesn't care about Tflush yet.
	- it only accepts files in the current directory.


# To unbundle, run this file
echo mkfile
sed 's/.//' >mkfile <<'//GO.SYSIN DD mkfile'
-</$objtype/mkfile
-BIN=$home/bin/$objtype
-
-TARG=watchfs
-OFILES=\
-	main.$O\
-
-</sys/src/cmd/mkone
//GO.SYSIN DD mkfile
echo main.c
sed 's/.//' >main.c <<'//GO.SYSIN DD main.c'
-#include <u.h>
-#include <libc.h>
-#include <auth.h>
-#include <fcall.h>
-#include <thread.h>
-#include <9p.h>
-
-int dbg;
-
-char *uname;
-Channel *cctl, *cctlwait;
-Channel *pctl, *pctlwait;
-Channel *creq;
-
-typedef struct Watchfile	Watchfile;
-struct Watchfile {
-	Ref;
-	Qid qid;
-	int fd;
-	char *name;
-	int dirty;
-};
-
-Watchfile wtab[10];
-int nw;
-
-void wtopen(Req*);
-void wtread(Req*);
-void wtwrite(Req*);
-void wtdestroyfid(Fid*);
-void takedown(Srv*);
-
-enum{
-	Qdata= 0,
-	Qctl= 1,
-
-	STACK = 8192,
-};
-
-int chatty9p;
-Srv fs = {
-	.open= wtopen,
-	.read= wtread,
-	.write= wtwrite,
-	.destroyfid = wtdestroyfid,
-	.end= takedown,
-};
-
-static void
-dumpQid(Dir *d)
-{
-	ulong path;
-	path = d->qid.path;
-	fprint(2, "name=%s qid=%lux\n", d->name, path);
-}
-
-static void
-dumpWF(void)
-{
-	int i;
-
-	for(i=0; i<nw; i++)
-		fprint(2, "dumpWF: %s %llud\n", wtab[i].name, wtab[i].qid.path);
-}	
-
-Watchfile *
-findtab(ulong path)
-{
-	int i;
-	for(i=0; i<nw; i++)
-		if(wtab[i].qid.path == path)
-			return &wtab[i];
-	return nil;
-}
-
-void
-wtopen(Req *r)
-{
-	ulong path;
-	Watchfile *wf;
-
-	path = r->fid->qid.path;
-	switch(path){
-	case Qctl:
-	case Qdata:
-		respond(r, nil);
-		return;
-	}
-
-	/* data/... */
-	wf = findtab(path);
-	if(wf == nil){
-		respond(r, "no file");
-		return;
-	}
-	if(dbg)
-		fprint(2, "wtopen: %s %ld fd %d\n", wf->name, wf->ref, wf->fd);
-
-	incref(wf);
-	if(wf->fd < 0){
-		wf->fd = open(wf->name, r->ifcall.mode);
-		wf->dirty = 0;
-	}
-	if(r->ifcall.mode&OTRUNC)
-		r->fid->file->length = 0;
-	respond(r, nil);
-}
-
-void
-wtread(Req *r)
-{
-	char buf[512];
-	int n;
-	ulong path;
-	Watchfile *wf;
-
-	path = r->fid->qid.path;
-	switch(path){
-	case Qdata:
-	case Qctl:
-		sendp(creq, r);
-		return;
-	}
-
-	/* data/... */
-	wf = findtab(r->fid->qid.path);
-	if(wf == nil){
-		respond(r, "no such qid");
-		return;
-	}
-	if(wf->fd < 0){
-		respond(r, "no fd");
-		return;
-	}
-	if(dbg)
-		fprint(2, "wtread: %s ref %ld fd %d\n", wf->name, wf->ref, wf->fd);
-	n = pread(wf->fd, r->ofcall.data, r->ifcall.count, r->ifcall.offset);
-	if(n < 0){
-		rerrstr(buf, sizeof buf);
-		respond(r, buf);
-		return;
-	}
-	r->ofcall.count = n;
-	respond(r, nil);
-}
-
-void
-wtwrite(Req *r)
-{
-	char buf[512];
-	int n;
-	ulong path;
-	vlong offset;
-	Watchfile *wf;
-
-	path = r->fid->qid.path;
-	offset = r->ifcall.offset;
-
-	switch(path){
-	case Qdata:
-	case Qctl:
-		snprint(buf, sizeof buf, "not yet %lux", path);
-		respond(r, buf);
-		return;
-	}
-
-	/* data/... */
-	wf = findtab(path);
-	if(wf == nil){
-		respond(r, "no such qid");
-		return;
-	}
-	if(dbg)
-		fprint(2, "wtwrite: %s ref %ld fd %d\n", wf->name, wf->ref, wf->fd);
-
-	if(wf->fd < 0){
-		respond(r, "no fd");
-		return;
-	}
-
-	n = pwrite(wf->fd, r->ifcall.data, r->ifcall.count, r->ifcall.offset);
-	if(n < 0){
-		rerrstr(buf, sizeof buf);
-		respond(r, buf);
-		return;
-	}
-	if(n+offset >= r->fid->file->length)
-		r->fid->file->length = n+offset;
-	wf->dirty++;
-	r->ofcall.count = n;
-	respond(r, nil);
-
-}
-
-void
-wtdestroyfid(Fid *fid)
-{
-	ulong path;
-	Watchfile *wf;
-
-	path = fid->qid.path;
-	wf = findtab(path);
-	if(wf == nil)
-		return;
-
-	if(dbg)
-		fprint(2, "wtdestroyfid: %s ref %ld fd %d\n", wf->name, wf->ref, wf->fd);
-
-	if(wf->fd >= 0){
-		if(decref(wf) == 0){
-			if(wf->dirty){
-				sendp(cctl, wf);
-				recvp(cctlwait);
-			}
-			close(wf->fd);
-			wf->fd = -1;
-			wf->dirty = 0;
-		}
-	}
-}
-
-Tree *
-inittree(char **argv)
-{
-	Tree *tree;
-	File *df;
-
-	tree = alloctree(uname, uname, DMDIR|0555, nil);
-	df = createfile(tree->root, "data", uname, DMDIR|0555, nil);
-	createfile(tree->root, "ctl", uname, 0660, nil);
-
-	for(;*argv;argv++){
-		File *f;
-		Dir *d;
-		d = dirstat(*argv);
-		if(d == nil)
-			continue;
-		if(dbg)
-			fprint(2, "dir: name %s len %lld\n", d->name, d->length);
-		f = createfile(df, *argv, uname, 0660, nil);
-		wtab[nw].qid = f->qid;
-		wtab[nw].name = estrdup9p(*argv);
-		wtab[nw].fd = -1;
-		f->length = d->length;
-		nw++;
-	}
-
-	return tree;
-}
-
-static void
-pollthread(void*)
-{
-	for(;;){
-		sleep(1);
-	}
-}
-
-static void
-ctlthread(void*)
-{
-	int i, np = 0;
-	Alt a[4];
-	Req *r, *rtab[10];
-	Watchfile *wf;
-
-	threadsetname("ctlthread");
-
-	a[0].op = CHANRCV;
-	a[0].c = creq;
-	a[0].v = &r;
-	a[1].op = CHANRCV;
-	a[1].c = cctl;
-	a[1].v = &wf;
-	a[2].op = CHANRCV;
-	a[2].c = pctl;
-	a[2].v = &wf;
-	a[3].op = CHANEND;
-
-	for(;;){
-		switch(alt(a)){
-		case 0: /* creq: someone tries to read ctl */
-			rtab[np++] = r;
-			break;
-
-		case 1: /* cctl: ready to serve ctl */
-			for(i=0; i<np; i++){
-				r = rtab[i];
-				snprint(r->ofcall.data, r->ifcall.count,
-					"%s %llud\n", wf->name, wf->qid.path);
-				r->ofcall.count = strlen(r->ofcall.data);
-				respond(r, nil);
-			}
-			np = 0;
-			sendp(cctlwait, 0);
-			break;
-
-		case 2: /* pctl: poll says modified */
-			for(i=0; i<np; i++){
-				r = rtab[i];
-				snprint(r->ofcall.data, r->ifcall.count,
-					"%s %llud\n", wf->name, wf->qid.path);
-				r->ofcall.count = strlen(r->ofcall.data);
-				respond(r, nil);
-			}
-			np = 0;
-			sendp(pctlwait, 0);
-			break;
-
-		default:
-			break;
-		}
-	}
-}
-
-void
-initctl(void)
-{
-	cctl = chancreate(sizeof(void*), 0);
-	cctlwait = chancreate(sizeof(void*), 0);
-	pctl = chancreate(sizeof(void*), 0);
-	pctlwait = chancreate(sizeof(void*), 0);
-	creq = chancreate(sizeof(void*), 0);
-	procrfork(ctlthread, nil, STACK, RFNAMEG);
-	procrfork(pollthread, nil, STACK, RFNAMEG);
-}
-
-void
-usage(void)
-{
-	fprint(2, "usage:  watchfs files...\n");
-}
-
-void
-threadmain(int argc, char *argv[])
-{
-
-	ARGBEGIN{
-	case 'd':
-		dbg++;
-		break;
-	case 'D':
-		chatty9p++;
-		break;
-	}ARGEND;
-
-	uname = getuser();
-
-	fs.tree = inittree(&argv[0]);
-	if(dbg)
-		dumpWF();
-
-	initctl();
-	threadpostmountsrv(&fs, nil, "/n/watch", MREPL|MCREATE);
-	threadexits(0);
-}
-
-void
-takedown(Srv*)
-{
-	threadexitsall("done");
-}
-
-
-
-
//GO.SYSIN DD main.c

Re: [9fans] watch command

[YAMANASHI Takeshi]

On Tue Apr 19 19:06:59 JST 2005, Charles Forsyth wrote:
> >>What am I missing?
> 
> nothing technical, just that he's probably willing to assume that all
> the accesses he cares about in this case will happen through that
> interposed file server, and in particular other users aren't involved.

Exactly. :)

Adding to the above points, it would work as a good introductory for me
to write a tiny file server using 9p(2).
-- 

Re: [9fans] watch command

[YAMANASHI Takeshi]

On Tue Apr 19 17:37:07 JST 2005, Fco. J. Ballesteros wrote:
> This is how we do it.
 :
>      NAME
>           poll - poll files for changes

Nice. :)

BTW, watchfs won't poll files.  Watchfs interposes itself
in the middle of a 9p transaction and send a message to
activate a program whenever it sees Tclunk on modified files.
-- 

Re: [9fans] watch command

[Fco. J. Ballesteros]

:  BTW, watchfs won't poll files.  Watchfs interposes itself
:  in the middle of a 9p transaction and send a message to
:  activate a program whenever it sees Tclunk on modified files.

But in that case you'd have to poll, don't you?
Otherwise, what do you do if some process changes the file
from outside (eg by mounting the fs where the real file stands).

What am I missing?

thanks

Re: [9fans] watch command

[Charles Forsyth]

>>What am I missing?

nothing technical, just that he's probably willing to assume that all
the accesses he cares about in this case will happen through that
interposed file server, and in particular other users aren't involved.

Re: [9fans] watch command

[Ronald G. Minnich]

On Tue, 19 Apr 2005, Fco. J. Ballesteros wrote:

> But in that case you'd have to poll, don't you?
> Otherwise, what do you do if some process changes the file
> from outside (eg by mounting the fs where the real file stands).
> 
> What am I missing?

I don't think you are missing anything, seems it would be nice to have a 
way to connect to a file server and say "tell me about metadata changes".

ron

Re: [9fans] watch command

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]


We tried with a change for fossil to tell about changes, but we
found that a change (suggested by rsc in the source) to propagate
mtimes upwards in the tree up to the root made it trivial to learn which
files changed since the last scan. BTW, our poll is not using that feature.

[-- Attachment #2: Type: message/rfc822, Size: 3025 bytes --]

From: "Ronald G. Minnich" <rminnich@lanl.gov>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] watch command
Date: Tue, 19 Apr 2005 09:01:49 -0600 (MDT)
Message-ID: <Pine.LNX.4.58.0504190901210.22161@enigma.lanl.gov>



On Tue, 19 Apr 2005, Fco. J. Ballesteros wrote:

> But in that case you'd have to poll, don't you?
> Otherwise, what do you do if some process changes the file
> from outside (eg by mounting the fs where the real file stands).
> 
> What am I missing?

I don't think you are missing anything, seems it would be nice to have a 
way to connect to a file server and say "tell me about metadata changes".

ron

Re: [9fans] watch command

[Lucio De Re]

> We tried with a change for fossil to tell about changes, but we
> found that a change (suggested by rsc in the source) to propagate
> mtimes upwards in the tree up to the root made it trivial to learn which
> files changed since the last scan. BTW, our poll is not using that feature.

That would be the key, wouldn't it?  If one could hook into the
fileserver to detect mtime changes, one would have the mechanism for
notification.  Possible?  I should think that the difficult part is to
stick to the Plan 9 way to do things.

++L

Re: [9fans] watch command

[Dan Cross]

Lucio De Re <lucio@proxima.alt.za> writes:
> That would be the key, wouldn't it?  If one could hook into the
> fileserver to detect mtime changes, one would have the mechanism for
> notification.  Possible?  I should think that the difficult part is to
> stick to the Plan 9 way to do things.

Anything is possible.  You're right that the ultimate challenge is to
keep it in the `Plan 9 way' of doing things.  A way to get out-of-band
notification of interesting file changes would be nice.

	- Dan C.

Re: [9fans] watch command

[Steve Simon]

> I don't think you are missing anything, seems it would be nice to have a 
> way to connect to a file server and say "tell me about metadata changes".

Windows does this.
 
I wanted to do this too, I considered making read(2)s beyond the end
of a directory block the calling process until any file in that
directory is modified.

I decided this is too nasty and added a synthetic event file instead.
This was fine as I had only a small heirarchy to serve not the general
one of a "real" file server.

-Steve

Re: [9fans] watch command

[boyd, rounin]

> I don't think you are missing anything, seems it would be nice to have a 
> way to connect to a file server and say "tell me about metadata changes".

i've done this portably for changes in persitant sql queries
and the data elements returned by the query.
--
MGRS 31U DQ 52572 12604

Re: [9fans] watch command

[Ronald G. Minnich]

On Tue, 19 Apr 2005, YAMANASHI Takeshi wrote:

> BTW, watchfs won't poll files.  Watchfs interposes itself in the middle
> of a 9p transaction and send a message to activate a program whenever it
> sees Tclunk on modified files.

now that is cool. Could you beat on iostats to do similar things?

ron

Re: [9fans] watch command

[YAMANASHI Takeshi]

> i'd forgotten about watch, but iirc it was meant to
> keep an eye on 1 file.

Yes.  But keeping both eyes on several files is a natural
extension to the original idea, isn't it?

> i would think hard before embarking on a mkfs.

Just executing "Put; mk" should fine for acme users.
Sadly enough, acme doesn't like the combination of
internal and external command.

	Put: '/bin/Put' file does not exist
	mk: nothing to mk
	rc 8436: mk 8438: error
-- 

Re: [9fans] watch command

[YAMANASHI Takeshi]

> Then, what is the purpose for?

Just as same as the original watch (troff type setting).
Actually, I'm doing a LaTeX work now, and thought it would be
handy if the "platex; xdvi" command chain is run automatically.

> I thought you are going to watch, say, kernel sources changed by
> someone else...

oh, it would be fun to see diff whenever some changed some file, too.
-- 

Re: [9fans] watch command

[Abhey Shah]

Don't know if if it'll work with plan 9 perl but atchange may be an 
option?
  http://www-lmmb.ncifcrf.gov/~toms/atchange.html

Abhey

On 19 Apr 2005, at 07:57, YAMANASHI Takeshi wrote:

>> Then, what is the purpose for?
>
> Just as same as the original watch (troff type setting).
> Actually, I'm doing a LaTeX work now, and thought it would be
> handy if the "platex; xdvi" command chain is run automatically.
>
>> I thought you are going to watch, say, kernel sources changed by
>> someone else...
>
> oh, it would be fun to see diff whenever some changed some file, too.
> -- 
>
>
>

Re: [9fans] watch command

[YAMANASHI Takeshi]

> In your example, are you going to have a huge list of files to be watched?

I tend to keep my working list rather small (~5 files).
I'm not such smart that I can manage a huge list of files.
-- 

Re: [9fans] watch command

[Kenji Okamoto]

>> In your example, are you going to have a huge list of files to be watched?
> 
> I tend to keep my working list rather small (~5 files).
> I'm not such smart that I can manage a huge list of files.

Then, what is the purpose for?
I thought you are going to watch, say, kernel sources changed by
someone else...

Kenji

Re: [9fans] watch command

[boyd, rounin]

> I tend to keep my working list rather small (~5 files).

i'd forgotten about watch, but iirc it was meant to
keep an eye on 1 file.

i would think hard before embarking on a mkfs.
--
MGRS 31U DQ 52572 12604

[9fans] watch command

[YAMANASHI Takeshi]

I read about "watch" command in the mpx paper (*) and thought
it's interesting.  The paper mentions the commandline:
	watch fig1.pic | pic | troff | proof
and the pipe line runs whenever fig1.pic is modified.
Does anyone have a similar program in his pocket?

(*) hget http://cm.bell-labs.com/cm/cs/doc/83/mpx.ps.gz | gunzip | page


I'm thinking of writing a file server (watchfs) which will serve:
  /n/watch/ctl
  /n/watch/data/a.c
  /n/watch/data/b.c

Whenever a.c and b.c are changed, a text will appear on the ctl file.
Thus, you can do something like:
	% while(){read /n/watch/ctl; mk}

How's this idea?
-- 

Re: [9fans] watch command

[Kenji Okamoto]

> Whenever a.c and b.c are changed, a text will appear on the ctl file.
> Thus, you can do something like:
> 	% while(){read /n/watch/ctl; mk}
> 
> How's this idea?

I've heard a Japanese talked on automatic counting of craters, where
it can, probably, recognise the crater right(?), actually which is the
problem here.   By the way, he is a programmer probably, and not a
Planetary geologist, and had thought it might be usefull.   Is it usefull?
No.

In your example, are you going to have a huge list of files to be watched?

Kenji

Re: [9fans] watch command

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

This is how we do it.

   POLL(1)               Plan B — 3rd edition                POLL(1)

     NAME
          poll - poll files for changes

     SYNOPSIS
          poll [ -1 ] [ -i ival ] cmd file...

     DESCRIPTION
          Poll monitors the given files each ival seconds (one by
          default) and runs cmd when any of the files change. It uses
          fstat(2) to generate a single stat(5) request for each poll
          and file. If -1 is given, the program exits after the first
          change noticed; otherwise, it keeps on polling the files.

          The command is assumed to be at /bin and is executing using
          the list of files as arguments.

     SOURCE
          /sys/src/cmd/poll.c

     Page 1                Plan B User's Manual      (printed 4/19/05)

[-- Attachment #2: Type: message/rfc822, Size: 3182 bytes --]

From: YAMANASHI Takeshi <9.nashi@gmail.com>
To: 9fans@cse.psu.edu
Subject: [9fans] watch command
Date: Tue, 19 Apr 2005 15:17:29 +0900
Message-ID: <fba2c2927e6c4dd58cd8a6ebd5ec1d86@orthanc.cc.titech.ac.jp>

I read about "watch" command in the mpx paper (*) and thought
it's interesting.  The paper mentions the commandline:
	watch fig1.pic | pic | troff | proof
and the pipe line runs whenever fig1.pic is modified.
Does anyone have a similar program in his pocket?

(*) hget http://cm.bell-labs.com/cm/cs/doc/83/mpx.ps.gz | gunzip | page


I'm thinking of writing a file server (watchfs) which will serve:
  /n/watch/ctl
  /n/watch/data/a.c
  /n/watch/data/b.c

Whenever a.c and b.c are changed, a text will appear on the ctl file.
Thus, you can do something like:
	% while(){read /n/watch/ctl; mk}

How's this idea?
--