Re: [9fans] Win32 9p, rangboom, etc
the installable filesystem (IFS) for windows hasn't been worked on in over a year. it really has gone as far as it needs to in the current state. there is a wish list of enhancements, but no time (or reason) to work on them now. the last major filesystem integration was done by brucee when he added support for FUSE (based on rsc' 9pfuse). i'm cleaning up the agent sources (mainly file arrangement) and will be putting up the sources in the near future. it will include everything BUT the IFS interface; no decision on releasing that. my main focus now is on improving namespace access through browsers rather than worrying about importing via 9p into native file systems. however the agent uses 9p to serve the namespace. i'm moving the web ui to GWT which should allow more features/flexibility. fgb finished a major component for this (cgifs) to ease feature development. a few people are working on integrating rangboom into their environment. perhaps they would describe their project if they wish. Rangboom is progressing, but it is competing with other priorities and commitments. -Skip > What is the current state of NT 9p filesystem drivers? > > I know Rangboom has one in their product (although I think > perhaps its not really used?). Do they plan to release > it in the future? Is the Rangboom fs driver reusable with > plan9 or inferno servers? If so, does anyone have information > on how to use the driver? Does anyone have any insights > into Rangboom's progress - ie. are they still around, and > making commercial progress? > > Is anyone working on an open source 9p filesystem driver > for NT?
Re: [9fans] i/o on a hangup channel asymmetry
On Mon Jul 20 22:05:50 EDT 2009, r...@swtch.com wrote: > The programs that know about the signal are > not the programs that need to be worried about. > I'm much more worried about making sure that > commands like > > grep pattern /n/dump/slow/slow/sys/log/mail | sed 5q > > stop as early as possible. The note is nice > precisely because it doesn't involve editing the > source for every command. if the grep has very few matches, it could process for quite a long time before needing to write at all. is this really effective in saving cpu? also, the only case that is a problem is when the return status of writes is not checked. (or am i missing something?) and the problem will resurface on a pipe accessed through the mount driver. - erik
Re: [9fans] i/o on a hangup channel asymmetry
The programs that know about the signal are not the programs that need to be worried about. I'm much more worried about making sure that commands like grep pattern /n/dump/slow/slow/sys/log/mail | sed 5q stop as early as possible. The note is nice precisely because it doesn't involve editing the source for every command. Russ
Re: [9fans] i/o on a hangup channel asymmetry
i did some looking through the plan 9 source.
(it's great to have it all in one place.)
all of this group, to a quick scan, should work
if the note is removed. many can lose their
note handlers, because the the pipe signal is
the only there to catch writes on closed pipes.
grep 'closed pipe' `{find . | grep '\.[chy]$'}
./9/port/devpipe.c: * a write to a closed pipe causes a note to be sent to
./9/port/devpipe.c: postnote(up, 1, "sys: write on closed
pipe", NUser);
./9/port/devpipe.c: postnote(up, 1, "sys: write on closed
pipe", NUser);
./ape/lib/ap/plan9/signal.c:{"sys: write on closed pipe",
SIGPIPE},
./cmd/con/con.c:if(strstr(msg, "closed pipe")
./cmd/sam/plan9.c: if(bpipeok && strcmp(s, "sys: write on closed pipe") ==
0)
./cmd/srv.c:if(strstr(c, "write on closed pipe") == 0){
./cmd/srv.c:fprint(2, "write on closed pipe\n");
./cmd/unix/drawterm/kern/devpipe.c: * a write to a closed pipe causes a note
to be sent to
./cmd/unix/drawterm/kern/devpipe.c: postnote(up, 1, "sys:
write on closed pipe", NUser);
./cmd/unix/drawterm/kern/devpipe.c: postnote(up, 1, "sys:
write on closed pipe", NUser);
./cmd/upas/common/libsys.c: * catch a write on a closed pipe
./cmd/upas/common/libsys.c: static char *foo = "sys: write on closed pipe";
./cmd/upas/imap4d/imap4d.c: if(strstr(msg, "closed pipe") != nil)
./cmd/upas/smtp/smtp.c: if(strstr(msg, "closed pipe")){
./cmd/upas/smtp/smtp.c: syslog(0, "smtp.fail", "%s closed pipe
to %s", deliverytype(), farend);
./cmd/upas/smtp/smtp.c: /* call _exits() to prevent Bio from trying to
flush closed pipe */
./libauth/newns.c:static char *wocp = "sys: write on closed pipe";
needs fixing:
./cmd/sort.c: if(strncmp(s, "sys: write on closed pipe", 25) == 0)
there's a write that is not checked for errors. this is already a bug.
patch already submitted.
- erik
Re: [9fans] dcp - a deep copy script, better than dircp
On Mon, Jul 20, 2009 at 6:56 PM, erik quanstrom wrote: > i know you can do it with du, but it seems a bit "cat -n"ish to me. > for comparison: This was why I wrote 'walk' a few years ago; du is the disk usage tool, not a general file walker. - Dan C.
Re: [9fans] dcp - a deep copy script, better than dircp
minooka; time rc -c 'du -a . | wc' > On Mon, Jul 20, 2009 at 2:41 PM, erik quanstrom wrote: > > on coraid's worm, a find on main takes not too long: > > > > minooka; cd /n/ila > > minooka; time rc -c 'find . | wc' > > 356164 356164 13987863 > > 1.24u 1.38s 6.65r rc -c find . | wc > > The FAQ also mentions: > > du -a . | grep foo > > Just out of curiosity, how does find vs du compare for you? i know you can do it with du, but it seems a bit "cat -n"ish to me. for comparison: minooka; time rc -c 'du -a . | wc' 356181 712362 14825492 1.91u 4.22s 8.66rrc -c du -a . | wc - erik
Re: [9fans] dcp - a deep copy script, better than dircp
On Mon, Jul 20, 2009 at 2:41 PM, erik quanstrom wrote: > on coraid's worm, a find on main takes not too long: > > minooka; cd /n/ila > minooka; time rc -c 'find . | wc' > 356164 356164 13987863 > 1.24u 1.38s 6.65r rc -c find . | wc The FAQ also mentions: du -a . | grep foo Just out of curiosity, how does find vs du compare for you? -Jack
Re: [9fans] dcp - a deep copy script, better than dircp
> > I think the latter approach would produce a more usable, less frustrating > filesystem than the former. > plan 9 seems to me to be firmly in the fs rather than the database camp. before i moved to plan 9, i thought that locate was a very cool tool. things had gotten mighty hard to find in linux. since i've moved to plan 9, i just don't have that problem. even when struck with real desperation on coraid's worm, a find on main takes not too long: minooka; cd /n/ila minooka; time rc -c 'find . | wc' 356164 356164 13987863 1.24u 1.38s 6.65rrc -c find . | wc - erik
Re: [9fans] dcp - a deep copy script, better than dircp
I've been thinking for a while that I don't quite like directories, as organizing metadata. Too restrictive: you can only really choose one place, to find something you already have to know where to look (or search through everything), and if you choose long, comprehensible names, your unique set of metadata to find a file becomes very long. Consider, by contrast, a service like Evernote.com (KPhotoAlbum also does tags well, and delicious.com for web pages). It has folders, yes, but what's better is that it lets you assign keywords to the note (really just arbitrary textual (or other) data). The note's topic is in essence the combination of all the keywords, so if you are interested in one of those keywords in the future, looking for the keyword (or some combination of keywords) would list all the notes with those keywords attached. I think the latter approach would produce a more usable, less frustrating filesystem than the former. Jason Catena
Re: [9fans] git on plan9
I don't think the porter's contrib has been created yet; I will happily host it on mine in the meantime, or other arrangements could be made. John On Mon, Jul 20, 2009 at 2:43 PM, Roman V Shaposhnik wrote: > On Mon, 2009-07-20 at 14:39 -0700, John Floren wrote: >> Hi >> Can I get a copy of your code? > > In fact, can it put in contrib ? > > Thanks, > Roman. > >> >> Thanks >> >> John >> >> On Sat, Jul 18, 2009 at 3:46 PM, wrote: >> > Phew finally got it. There was some hackery involved in the hg-git >> > python code since mmap wasn't supported -- i basically just implemented >> > them with reads; however I was considering writing an mmap module that >> > used reads but realized that would be misleading since it wasn't really >> > mmap. I think altering the hg-git code is the best option and i've done >> > it in such a way that its isolated so it can be easily updated from >> > mainstream. Let me know if you want it. >> > >> > ++james >> > >> > rator_gade% hg clone git://zen-sources.org/zen/THE.git >> > destination directory: THE.git >> > fetching from : git://zen-sources.org/zen/THE.git >> > importing Hg objects into Git >> > Counting objects: 1592, done. >> > Compressing objects: 0% (1/1185) >> > Compressing objects: 1% (12/1185) >> > Compressing objects: 2% (24/1185) >> > Compressing objects: 3% (36/1185) >> > Compressing objects: 4% (48/1185) >> > Compressing objects: 5% (60/1185) >> > Compressing objects: 6% (72/1185) >> > Compressing objects: 7% (83/1185) >> > Compressing objects: 8% (95/1185) >> > Compressing objects: 9% (107/1185) >> > Compressing objects: 10% (119/1185) >> > Compressing objects: 11% (131/1185) >> > Compressing objects: 12% (143/1185) >> > Compressing objects: 13% (155/1185) >> > Compressing objects: 14% (166/1185) >> > Compressing objects: 15% (178/1185) >> > Compressing objects: 16% (190/1185) >> > Compressing objects: 17% (202/1185) >> > Compressing objects: 18% (214/1185) >> > Compressing objects: 19% (226/1185) >> > Compressing objects: 20% (237/1185) >> > Compressing objects: 21% (249/1185) >> > Compressing objects: 22% (261/1185) >> > Compressing objects: 23% (273/1185) >> > Compressing objects: 24% (285/1185) >> > Compressing objects: 25% (297/1185) >> > Compressing objects: 26% (309/1185) >> > Compressing objects: 27% (320/1185) >> > Compressing objects: 28% (332/1185) >> > Compressing objects: 29% (344/1185) >> > Compressing objects: 30% (356/1185) >> > Compressing objects: 31% (368/1185) >> > Compressing objects: 32% (380/1185) >> > Compressing objects: 33% (392/1185) >> > Compressing objects: 34% (403/1185) >> > Compressing objects: 35% (415/1185) >> > Compressing objects: 36% (427/1185) >> > Compressing objects: 37% (439/1185) >> > Compressing objects: 38% (451/1185) >> > Compressing objects: 39% (463/1185) >> > Compressing objects: 40% (474/1185) >> > Compressing objects: 41% (486/1185) >> > Compressing objects: 42% (498/1185) >> > Compressing objects: 43% (510/1185) >> > Compressing objects: 44% (522/1185) >> > Compressing objects: 45% (534/1185) >> > Compressing objects: 46% (546/1185) >> > Compressing objects: 47% (557/1185) >> > Compressing objects: 48% (569/1185) >> > Compressing objects: 49% (581/1185) >> > Compressing objects: 50% (593/1185) >> > Compressing objects: 51% (605/1185) >> > Compressing objects: 52% (617/1185) >> > Compressing objects: 53% (629/1185) >> > Compressing objects: 54% (640/1185) >> > Compressing objects: 55% (652/1185) >> > Compressing objects: 56% (664/1185) >> > Compressing objects: 57% (676/1185) >> > Compressing objects: 58% (688/1185) >> > Compressing objects: 59% (700/1185) >> > Compressing objects: 60% (711/1185) >> > Compressing objects: 61% (723/1185) >> > Compressing objects: 62% (735/1185) >> > Compressing objects: 63% (747/1185) >> > Compressing objects: 64% (759/1185) >> > Compressing objects: 65% (771/1185) >> > Compressing objects: 66% (783/1185) >> > Compressing objects: 67% (794/1185) >> > Compressing objects: 68% (806/1185) >> > Compressing objects: 69% (818/1185) >> > Compressing objects: 70% (830/1185) >> > Compressing objects: 71% (842/1185) >> > Compressing objects: 72% (854/1185) >> > Compressing objects: 73% (866/1185) >> > Compressing objects: 74% (877/1185) >> > Compressing objects: 75% (889/1185) >> > Compressing objects: 76% (901/1185) >> > Compressing objects: 77% (913/1185) >> > Compressing objects: 78% (925/1185) >> > Compressing objects: 79% (937/1185) >> > Compressing objects: 80% (948/1185) >> > Compressing objects: 81% (960/1185) >> > Compressing objects: 82% (972/1185) >> > Compressing objects: 83% (984/1185) >> > Compressing objects: 84% (996/1185) >> > Compressing objects: 85% (1008/1185) >> > Compressing objects: 86% (1020/1185) >> > Compressing objects: 87% (1031/1185) >> > Compressing objects: 88% (1043/1185) >> > Compressing objects: 89% (1055/1185) >> > Compressing objects: 90% (
Re: [9fans] git on plan9
On Mon, 2009-07-20 at 14:39 -0700, John Floren wrote: > Hi > Can I get a copy of your code? In fact, can it put in contrib ? Thanks, Roman. > > Thanks > > John > > On Sat, Jul 18, 2009 at 3:46 PM, wrote: > >Phew finally got it. There was some hackery involved in the hg-git > > python code since mmap wasn't supported -- i basically just implemented > > them with reads; however I was considering writing an mmap module that used > > reads but realized that would be misleading since it wasn't really mmap. I > > think altering the hg-git code is the best option and i've done it in such > > a way that its isolated so it can be easily updated from mainstream. Let > > me know if you want it. > > > > ++james > > > > rator_gade% hg clone git://zen-sources.org/zen/THE.git > > destination directory: THE.git > > fetching from : git://zen-sources.org/zen/THE.git > > importing Hg objects into Git > > Counting objects: 1592, done. > > Compressing objects: 0% (1/1185) > > Compressing objects: 1% (12/1185) > > Compressing objects: 2% (24/1185) > > Compressing objects: 3% (36/1185) > > Compressing objects: 4% (48/1185) > > Compressing objects: 5% (60/1185) > > Compressing objects: 6% (72/1185) > > Compressing objects: 7% (83/1185) > > Compressing objects: 8% (95/1185) > > Compressing objects: 9% (107/1185) > > Compressing objects: 10% (119/1185) > > Compressing objects: 11% (131/1185) > > Compressing objects: 12% (143/1185) > > Compressing objects: 13% (155/1185) > > Compressing objects: 14% (166/1185) > > Compressing objects: 15% (178/1185) > > Compressing objects: 16% (190/1185) > > Compressing objects: 17% (202/1185) > > Compressing objects: 18% (214/1185) > > Compressing objects: 19% (226/1185) > > Compressing objects: 20% (237/1185) > > Compressing objects: 21% (249/1185) > > Compressing objects: 22% (261/1185) > > Compressing objects: 23% (273/1185) > > Compressing objects: 24% (285/1185) > > Compressing objects: 25% (297/1185) > > Compressing objects: 26% (309/1185) > > Compressing objects: 27% (320/1185) > > Compressing objects: 28% (332/1185) > > Compressing objects: 29% (344/1185) > > Compressing objects: 30% (356/1185) > > Compressing objects: 31% (368/1185) > > Compressing objects: 32% (380/1185) > > Compressing objects: 33% (392/1185) > > Compressing objects: 34% (403/1185) > > Compressing objects: 35% (415/1185) > > Compressing objects: 36% (427/1185) > > Compressing objects: 37% (439/1185) > > Compressing objects: 38% (451/1185) > > Compressing objects: 39% (463/1185) > > Compressing objects: 40% (474/1185) > > Compressing objects: 41% (486/1185) > > Compressing objects: 42% (498/1185) > > Compressing objects: 43% (510/1185) > > Compressing objects: 44% (522/1185) > > Compressing objects: 45% (534/1185) > > Compressing objects: 46% (546/1185) > > Compressing objects: 47% (557/1185) > > Compressing objects: 48% (569/1185) > > Compressing objects: 49% (581/1185) > > Compressing objects: 50% (593/1185) > > Compressing objects: 51% (605/1185) > > Compressing objects: 52% (617/1185) > > Compressing objects: 53% (629/1185) > > Compressing objects: 54% (640/1185) > > Compressing objects: 55% (652/1185) > > Compressing objects: 56% (664/1185) > > Compressing objects: 57% (676/1185) > > Compressing objects: 58% (688/1185) > > Compressing objects: 59% (700/1185) > > Compressing objects: 60% (711/1185) > > Compressing objects: 61% (723/1185) > > Compressing objects: 62% (735/1185) > > Compressing objects: 63% (747/1185) > > Compressing objects: 64% (759/1185) > > Compressing objects: 65% (771/1185) > > Compressing objects: 66% (783/1185) > > Compressing objects: 67% (794/1185) > > Compressing objects: 68% (806/1185) > > Compressing objects: 69% (818/1185) > > Compressing objects: 70% (830/1185) > > Compressing objects: 71% (842/1185) > > Compressing objects: 72% (854/1185) > > Compressing objects: 73% (866/1185) > > Compressing objects: 74% (877/1185) > > Compressing objects: 75% (889/1185) > > Compressing objects: 76% (901/1185) > > Compressing objects: 77% (913/1185) > > Compressing objects: 78% (925/1185) > > Compressing objects: 79% (937/1185) > > Compressing objects: 80% (948/1185) > > Compressing objects: 81% (960/1185) > > Compressing objects: 82% (972/1185) > > Compressing objects: 83% (984/1185) > > Compressing objects: 84% (996/1185) > > Compressing objects: 85% (1008/1185) > > Compressing objects: 86% (1020/1185) > > Compressing objects: 87% (1031/1185) > > Compressing objects: 88% (1043/1185) > > Compressing objects: 89% (1055/1185) > > Compressing objects: 90% (1067/1185) > > Compressing objects: 91% (1079/1185) > > Compressing objects: 92% (1091/1185) > > Compressing objects: 93% (1103/1185) > > Compressing objects: 94% (1114/1185) > > Compressing objects: 95% (1126/1185) > > Compressing objects: 96% (1138/1185) > > Compressing objects: 97% (1150/1185) > > Compressing objects:
Re: [9fans] git on plan9
Hi Can I get a copy of your code? Thanks John On Sat, Jul 18, 2009 at 3:46 PM, wrote: > Phew finally got it. There was some hackery involved in the hg-git > python code since mmap wasn't supported -- i basically just implemented them > with reads; however I was considering writing an mmap module that used reads > but realized that would be misleading since it wasn't really mmap. I think > altering the hg-git code is the best option and i've done it in such a way > that its isolated so it can be easily updated from mainstream. Let me know > if you want it. > > ++james > > rator_gade% hg clone git://zen-sources.org/zen/THE.git > destination directory: THE.git > fetching from : git://zen-sources.org/zen/THE.git > importing Hg objects into Git > Counting objects: 1592, done. > Compressing objects: 0% (1/1185) > Compressing objects: 1% (12/1185) > Compressing objects: 2% (24/1185) > Compressing objects: 3% (36/1185) > Compressing objects: 4% (48/1185) > Compressing objects: 5% (60/1185) > Compressing objects: 6% (72/1185) > Compressing objects: 7% (83/1185) > Compressing objects: 8% (95/1185) > Compressing objects: 9% (107/1185) > Compressing objects: 10% (119/1185) > Compressing objects: 11% (131/1185) > Compressing objects: 12% (143/1185) > Compressing objects: 13% (155/1185) > Compressing objects: 14% (166/1185) > Compressing objects: 15% (178/1185) > Compressing objects: 16% (190/1185) > Compressing objects: 17% (202/1185) > Compressing objects: 18% (214/1185) > Compressing objects: 19% (226/1185) > Compressing objects: 20% (237/1185) > Compressing objects: 21% (249/1185) > Compressing objects: 22% (261/1185) > Compressing objects: 23% (273/1185) > Compressing objects: 24% (285/1185) > Compressing objects: 25% (297/1185) > Compressing objects: 26% (309/1185) > Compressing objects: 27% (320/1185) > Compressing objects: 28% (332/1185) > Compressing objects: 29% (344/1185) > Compressing objects: 30% (356/1185) > Compressing objects: 31% (368/1185) > Compressing objects: 32% (380/1185) > Compressing objects: 33% (392/1185) > Compressing objects: 34% (403/1185) > Compressing objects: 35% (415/1185) > Compressing objects: 36% (427/1185) > Compressing objects: 37% (439/1185) > Compressing objects: 38% (451/1185) > Compressing objects: 39% (463/1185) > Compressing objects: 40% (474/1185) > Compressing objects: 41% (486/1185) > Compressing objects: 42% (498/1185) > Compressing objects: 43% (510/1185) > Compressing objects: 44% (522/1185) > Compressing objects: 45% (534/1185) > Compressing objects: 46% (546/1185) > Compressing objects: 47% (557/1185) > Compressing objects: 48% (569/1185) > Compressing objects: 49% (581/1185) > Compressing objects: 50% (593/1185) > Compressing objects: 51% (605/1185) > Compressing objects: 52% (617/1185) > Compressing objects: 53% (629/1185) > Compressing objects: 54% (640/1185) > Compressing objects: 55% (652/1185) > Compressing objects: 56% (664/1185) > Compressing objects: 57% (676/1185) > Compressing objects: 58% (688/1185) > Compressing objects: 59% (700/1185) > Compressing objects: 60% (711/1185) > Compressing objects: 61% (723/1185) > Compressing objects: 62% (735/1185) > Compressing objects: 63% (747/1185) > Compressing objects: 64% (759/1185) > Compressing objects: 65% (771/1185) > Compressing objects: 66% (783/1185) > Compressing objects: 67% (794/1185) > Compressing objects: 68% (806/1185) > Compressing objects: 69% (818/1185) > Compressing objects: 70% (830/1185) > Compressing objects: 71% (842/1185) > Compressing objects: 72% (854/1185) > Compressing objects: 73% (866/1185) > Compressing objects: 74% (877/1185) > Compressing objects: 75% (889/1185) > Compressing objects: 76% (901/1185) > Compressing objects: 77% (913/1185) > Compressing objects: 78% (925/1185) > Compressing objects: 79% (937/1185) > Compressing objects: 80% (948/1185) > Compressing objects: 81% (960/1185) > Compressing objects: 82% (972/1185) > Compressing objects: 83% (984/1185) > Compressing objects: 84% (996/1185) > Compressing objects: 85% (1008/1185) > Compressing objects: 86% (1020/1185) > Compressing objects: 87% (1031/1185) > Compressing objects: 88% (1043/1185) > Compressing objects: 89% (1055/1185) > Compressing objects: 90% (1067/1185) > Compressing objects: 91% (1079/1185) > Compressing objects: 92% (1091/1185) > Compressing objects: 93% (1103/1185) > Compressing objects: 94% (1114/1185) > Compressing objects: 95% (1126/1185) > Compressing objects: 96% (1138/1185) > Compressing objects: 97% (1150/1185) > Compressing objects: 98% (1162/1185) > Compressing objects: 99% (1174/1185) > Compressing objects: 100% (1185/1185) > Compressing objects: 100% (1185/1185), done. > Total 1592 (delta 455), reused 1128 (delta 286) > importing Git objects into Hg > at: 0/116 > at: 100/116 > updating working directory > 241 files updated, 0 files merged, 0 files removed, 0 files unre
Re: [9fans] git on plan9
That should have been a private reply, but I suck at using gmail. John On Mon, Jul 20, 2009 at 2:39 PM, John Floren wrote: > Hi > Can I get a copy of your code? > > Thanks > > John > > On Sat, Jul 18, 2009 at 3:46 PM, wrote: >> Phew finally got it. There was some hackery involved in the hg-git >> python code since mmap wasn't supported -- i basically just implemented them >> with reads; however I was considering writing an mmap module that used reads >> but realized that would be misleading since it wasn't really mmap. I think >> altering the hg-git code is the best option and i've done it in such a way >> that its isolated so it can be easily updated from mainstream. Let me know >> if you want it. >> >> ++james >> >> rator_gade% hg clone git://zen-sources.org/zen/THE.git >> destination directory: THE.git >> fetching from : git://zen-sources.org/zen/THE.git >> importing Hg objects into Git >> Counting objects: 1592, done. >> Compressing objects: 0% (1/1185) >> Compressing objects: 1% (12/1185) >> Compressing objects: 2% (24/1185) >> Compressing objects: 3% (36/1185) >> Compressing objects: 4% (48/1185) >> Compressing objects: 5% (60/1185) >> Compressing objects: 6% (72/1185) >> Compressing objects: 7% (83/1185) >> Compressing objects: 8% (95/1185) >> Compressing objects: 9% (107/1185) >> Compressing objects: 10% (119/1185) >> Compressing objects: 11% (131/1185) >> Compressing objects: 12% (143/1185) >> Compressing objects: 13% (155/1185) >> Compressing objects: 14% (166/1185) >> Compressing objects: 15% (178/1185) >> Compressing objects: 16% (190/1185) >> Compressing objects: 17% (202/1185) >> Compressing objects: 18% (214/1185) >> Compressing objects: 19% (226/1185) >> Compressing objects: 20% (237/1185) >> Compressing objects: 21% (249/1185) >> Compressing objects: 22% (261/1185) >> Compressing objects: 23% (273/1185) >> Compressing objects: 24% (285/1185) >> Compressing objects: 25% (297/1185) >> Compressing objects: 26% (309/1185) >> Compressing objects: 27% (320/1185) >> Compressing objects: 28% (332/1185) >> Compressing objects: 29% (344/1185) >> Compressing objects: 30% (356/1185) >> Compressing objects: 31% (368/1185) >> Compressing objects: 32% (380/1185) >> Compressing objects: 33% (392/1185) >> Compressing objects: 34% (403/1185) >> Compressing objects: 35% (415/1185) >> Compressing objects: 36% (427/1185) >> Compressing objects: 37% (439/1185) >> Compressing objects: 38% (451/1185) >> Compressing objects: 39% (463/1185) >> Compressing objects: 40% (474/1185) >> Compressing objects: 41% (486/1185) >> Compressing objects: 42% (498/1185) >> Compressing objects: 43% (510/1185) >> Compressing objects: 44% (522/1185) >> Compressing objects: 45% (534/1185) >> Compressing objects: 46% (546/1185) >> Compressing objects: 47% (557/1185) >> Compressing objects: 48% (569/1185) >> Compressing objects: 49% (581/1185) >> Compressing objects: 50% (593/1185) >> Compressing objects: 51% (605/1185) >> Compressing objects: 52% (617/1185) >> Compressing objects: 53% (629/1185) >> Compressing objects: 54% (640/1185) >> Compressing objects: 55% (652/1185) >> Compressing objects: 56% (664/1185) >> Compressing objects: 57% (676/1185) >> Compressing objects: 58% (688/1185) >> Compressing objects: 59% (700/1185) >> Compressing objects: 60% (711/1185) >> Compressing objects: 61% (723/1185) >> Compressing objects: 62% (735/1185) >> Compressing objects: 63% (747/1185) >> Compressing objects: 64% (759/1185) >> Compressing objects: 65% (771/1185) >> Compressing objects: 66% (783/1185) >> Compressing objects: 67% (794/1185) >> Compressing objects: 68% (806/1185) >> Compressing objects: 69% (818/1185) >> Compressing objects: 70% (830/1185) >> Compressing objects: 71% (842/1185) >> Compressing objects: 72% (854/1185) >> Compressing objects: 73% (866/1185) >> Compressing objects: 74% (877/1185) >> Compressing objects: 75% (889/1185) >> Compressing objects: 76% (901/1185) >> Compressing objects: 77% (913/1185) >> Compressing objects: 78% (925/1185) >> Compressing objects: 79% (937/1185) >> Compressing objects: 80% (948/1185) >> Compressing objects: 81% (960/1185) >> Compressing objects: 82% (972/1185) >> Compressing objects: 83% (984/1185) >> Compressing objects: 84% (996/1185) >> Compressing objects: 85% (1008/1185) >> Compressing objects: 86% (1020/1185) >> Compressing objects: 87% (1031/1185) >> Compressing objects: 88% (1043/1185) >> Compressing objects: 89% (1055/1185) >> Compressing objects: 90% (1067/1185) >> Compressing objects: 91% (1079/1185) >> Compressing objects: 92% (1091/1185) >> Compressing objects: 93% (1103/1185) >> Compressing objects: 94% (1114/1185) >> Compressing objects: 95% (1126/1185) >> Compressing objects: 96% (1138/1185) >> Compressing objects: 97% (1150/1185) >> Compressing objects: 98% (1162/1185) >> Compressing objects: 99% (1174/1185) >> Compressing objects: 100% (1185/1185
[9fans] Win32 9p, rangboom, etc
What is the current state of NT 9p filesystem drivers? I know Rangboom has one in their product (although I think perhaps its not really used?). Do they plan to release it in the future? Is the Rangboom fs driver reusable with plan9 or inferno servers? If so, does anyone have information on how to use the driver? Does anyone have any insights into Rangboom's progress - ie. are they still around, and making commercial progress? Is anyone working on an open source 9p filesystem driver for NT? Tim Newsham http://www.thenewsh.com/~newsham/
Re: [9fans] new usb stack and implicit timeouts
fd = open("/some/ctl", OWRITE);
write(fd, "timeout LONG_ENOUGH", length);
close(fd);
On Mon, Jul 20, 2009 at 2:10 PM, Lyndon Nerenberg wrote:
>> I am unsure I would remove timeouts even from bulk endpoints.
>> It is true that some devices (the usb/serial for example) need to
>> read for an undefined time waiting for data, but I don't think that is
>> an issue as long
>> as the timeouts are long enough,
>
> Please show us the algorithm that *correctly* determines 'long enough' for
> every application talking to the devices.
>
>
Re: [9fans] dcp - a deep copy script, better than dircp
On Mon, 20 Jul 2009 11:19:16 -0400 Dan Cross wrote: > On Mon, Jul 20, 2009 at 11:02 AM, Ethan > Grammatikidis wrote: > > Sorry if that was a bit harsh, but I've had far too much 'advice' to 'just > > do this easy little thing'... Computers are supposed to supplement the > > brain, to help, not require more (and in some cases quite impossible) work. > > To file anything so you can find it again requires experience in filing > > that particular information type. I'm constantly dealing with new data... > > Not to criticize, but I think the suggestion that Steve is making is > that, in order to better use the computer to supplement the brain and > help, it's best to use the tools of this particular computer system in > the most natural way, versus trying to use it as merely an improved > Linux or Unix or what have you. This is about my data, in files, on a filesystem. If Plan 9 has difficult restrictions in it's filesystem model then yeah, I have to use something else, but where else can I find namespaces and 9p? Ok, Inferno & Octopus; the latter I ought to have a look at, the former might work for me but I found Plan 9 a couple of years earlier, I feel a little bit more sure of where I am with Plan 9, and Inferno is frankly a bit messy. I suppose you guys think I'll make my Plan 9 installation 'a bit messy' if I carry on, eh? You may be right. :) Ugh, you got me _thinking_. :) If you have time for a mini-essay on Plan 9 and human beings, read on. What I really want to say is there's nothing natural about not letting user X reorganise his stuff. The world is change, the universe is changing constantly, if slowly. Humans are adapted to that change, some better than others, but more than that we're part of the changing world. We change, we grow, and we don't have all possible ideas pertaining to X the moment we acquire X. Some 'see' more than others, and quicker, and those I guess are better equipped to organize their data naturally as they acquire it, but give them a completely new field of data to work with and I'm sure they would initially be as disorganized as anyone else and would soon find they would have to reorganize. I realize I don't want Plan 9 exactly as it is. I already knew I didn't want the available user interfaces _quite_ the way they are and this discussion provides me with something else to think about in that regard. However I do seriously want 9p, namespaces, process isolation, interface simplicity... The potential value these features have in relation to the goals I would like to achieve is incalculable! However, to achieve my goals I have to work with the rest of Plan 9. I have to bend it until I can use it to get where I want to go. *sigh* Now you've got me thinking about seperate types of filesystems for user data and system data, or perhaps personal data and public data. I have other things to do, dammit. >:D -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] new usb stack and implicit timeouts
I am unsure I would remove timeouts even from bulk endpoints. It is true that some devices (the usb/serial for example) need to read for an undefined time waiting for data, but I don't think that is an issue as long as the timeouts are long enough, Please show us the algorithm that *correctly* determines 'long enough' for every application talking to the devices.
Re: [9fans] i/o on a hangup channel asymmetry
you're right. i wasn't thinking correctly.--- Begin Message --- On Mon, 2009-07-20 at 10:53 +0100, Charles Forsyth wrote: > >pipe would return -1 (and set a error condition) and the > >applications were paying attention (and I'm pretty sure all > >applications on Plan 9 would do a reasonable thing when > >presented with -1 from a write). > > they only notice when the write occurs. suppose that takes > several minutes of computation. Just to correct the statement of fact: same as true for the note -- it only gets sent when the write occurs. Thus -- there's no difference, really. Thanks, Roman. --- End Message ---
Re: [9fans] i/o on a hangup channel asymmetry
On Mon, 2009-07-20 at 10:52 +0100, Charles Forsyth wrote:
> you don't really want to get "write error" printed from every
> process in a pipe line such as
As much as I thought that could be an issue, I could NOT actually
make many of the commands I tried produce this message on a
modified 9vx:
term% ls | date
Some did produce a message, but somehow it didn't look all that
problematic (helpful, in fact -- letting me know that somewhere
in my pipe there was a problem and not all of the data went through):
term% awk 'BEGIN { printf("Hello\n"); }' | date
awk: write error on stdout
> slowly-compute-big-file | dosomemore | andyetmore | sed -n
> '/something/;p;q'
> or even
> slowly-compute-big-file | badusageofsomething
> where the latter prints a "usage" message and quits.
> you want to make sure the previous commands in the pipeline stop, right away.
One again -- just to make things clear -- slowly-compute-big-file WILL
NOT stop before it attempts the first actual write on a closed pipe. It
will merrily compute away. A trivial:
cpu% sleep 100 | sleep 1
would be enough to verify your hypothesis.
Thanks,
Roman.
Re: [9fans] i/o on a hangup channel asymmetry
On Mon, 2009-07-20 at 10:53 +0100, Charles Forsyth wrote: > >pipe would return -1 (and set a error condition) and the > >applications were paying attention (and I'm pretty sure all > >applications on Plan 9 would do a reasonable thing when > >presented with -1 from a write). > > they only notice when the write occurs. suppose that takes > several minutes of computation. Just to correct the statement of fact: same as true for the note -- it only gets sent when the write occurs. Thus -- there's no difference, really. Thanks, Roman.
Re: [9fans] i/o on a hangup channel asymmetry
On Mon, 2009-07-20 at 01:21 -0400, erik quanstrom wrote:
> > one last kick of a dead horse: see that's exactly what I'm
> > talking about -- all these exceptions and for what? I'm
> > pretty sure if we change the devpipe today not to send
> > a note nobody would even notice...
>
> since you're confident that this exception is spurious,
> why don't you remove it from your kernel? your
> argument would be much more convincing if you had
> evidence that after a couple million pids, your cpu
> server has experienced no funnies.
This does look like a curious experiment. Now, since I don't
run a native Plan9 kernel, I did modify 9vx (one can't thank
Russ enough for providing it!):
--- a/src/9vx/a/devpipe.c
+++ b/src/9vx/a/devpipe.c
@@ -313,8 +313,9 @@ pipewrite(Chan *c, void *va, long n, vlong offset)
print("pipewrite hi %lux\n", getcallerpc(&c));
if(waserror()) {
/* avoid notes when pipe is a mounted queue */
- if((c->flag & CMSG) == 0)
+ /* if((c->flag & CMSG) == 0)
postnote(up, 1, "sys: write on closed pipe", NUser);
+*/
nexterror();
}
@@ -345,8 +346,9 @@ pipebwrite(Chan *c, Block *bp, ulong offset)
if(waserror()) {
/* avoid notes when pipe is a mounted queue */
- if((c->flag & CMSG) == 0)
+ /* if((c->flag & CMSG) == 0)
postnote(up, 1, "sys: write on closed pipe", NUser);
+*/
nexterror();
}
So far so good. The test2.c now returns -1 "i/o on a hangup channel" from write
and the rest of the system seems to be pretty stable.
The usual pipelines that I run ("ls | sort", "...|awk", "...|sed") all seem to
be doing quite well.
Unfortunately I don't think I can get to a couple of million pids in my
9vx as you've suggested. So I guess, in the end, it doesn't count,
right?
Thanks,
Roman.
Re: [9fans] new usb stack and implicit timeouts
That is what I was considering instead of alarm-threadnotify (provided that the time out code in the kernel has to be kept there, for ctl transfers). But I'd like to provide the interface as it should be (otherewise there will be surprises). On Mon, Jul 20, 2009 at 5:07 PM, Dan Cross wrote: > Pardon me if this is totally ignorant, but can't we just have a ctl > message to control a timeout, which applications may then set on their > own? > > On Mon, Jul 20, 2009 at 3:12 AM, Gorka Guardiola wrote: >> On Sun, Jul 19, 2009 at 5:58 PM, Francisco J Ballesteros >> wrote: >>> On Sun, Jul 19, 2009 at 5:46 PM, wrote: http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket >>> >>> IIRC, I think the host controller is responsible for timing out >>> requests sent to the device (I refer to setup packets), but my uchi >>> does not. In any case, I don't think anyone wants to remove timeouts >>> from ctl requests. >>> >>> >> >> I am unsure I would remove timeouts even from bulk endpoints. >> It is true that some devices (the usb/serial for example) need to >> read for an undefined time waiting for data, but I don't think that is >> an issue as long >> as the timeouts are long enough, doing polling is quite easy. There is >> polling in the >> lower levels anyway. >> >> On the other hand, I think smart card readers go for >> lunch on a read and may never come >> back if there is no timeout. Of course alarm() can be used, but >> a timeout makes it simpler. I prefer having to poll on some >> cases than having to use signals on others. >> >> -- >> - curiosity sKilled the cat >> >> > >
Re: [9fans] dcp - a deep copy script, better than dircp
On Mon, Jul 20, 2009 at 11:02 AM, Ethan Grammatikidis wrote: > Sorry if that was a bit harsh, but I've had far too much 'advice' to 'just do > this easy little thing'... Computers are supposed to supplement the brain, to > help, not require more (and in some cases quite impossible) work. To file > anything so you can find it again requires experience in filing that > particular information type. I'm constantly dealing with new data... Not to criticize, but I think the suggestion that Steve is making is that, in order to better use the computer to supplement the brain and help, it's best to use the tools of this particular computer system in the most natural way, versus trying to use it as merely an improved Linux or Unix or what have you. Now, I'm not suggesting that you don't understand Plan 9, or that the underlying reasons you are moving directories around aren't valid, of course! If you're data is new, then good to go. If not, then I think the advise is for some things that you may find simplify your life, not make it harder.
Re: [9fans] dcp - a deep copy script, better than dircp
> Sure. Let me get a modest little cybernetic interface to one of those > temporal vision thingummabobs they have these days and I'll call you right > back. > > Sorry if that was a bit harsh, but I've had far too much 'advice' to 'just do > this easy little thing'... Computers are supposed to supplement the brain, to > help, not require more (and in some cases quite impossible) work. To file > anything so you can find it again requires experience in filing that > particular information type. I'm constantly dealing with new data... 9fans interface: 1. principles of operation 9fans is a forum where one can make statements and ask questions. those asking questions must be prepared to accept answers. [...] - erik
Re: [9fans] new usb stack and implicit timeouts
Pardon me if this is totally ignorant, but can't we just have a ctl message to control a timeout, which applications may then set on their own? On Mon, Jul 20, 2009 at 3:12 AM, Gorka Guardiola wrote: > On Sun, Jul 19, 2009 at 5:58 PM, Francisco J Ballesteros wrote: >> On Sun, Jul 19, 2009 at 5:46 PM, wrote: >>> http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket >>> >> >> IIRC, I think the host controller is responsible for timing out >> requests sent to the device (I refer to setup packets), but my uchi >> does not. In any case, I don't think anyone wants to remove timeouts >> from ctl requests. >> >> > > I am unsure I would remove timeouts even from bulk endpoints. > It is true that some devices (the usb/serial for example) need to > read for an undefined time waiting for data, but I don't think that is > an issue as long > as the timeouts are long enough, doing polling is quite easy. There is > polling in the > lower levels anyway. > > On the other hand, I think smart card readers go for > lunch on a read and may never come > back if there is no timeout. Of course alarm() can be used, but > a timeout makes it simpler. I prefer having to poll on some > cases than having to use signals on others. > > -- > - curiosity sKilled the cat > >
Re: [9fans] dcp - a deep copy script, better than dircp
On Mon, 20 Jul 2009 15:00:43 +0100 "Steve Simon" wrote: > > ...c-stoff/t-stoff powered rocket... > > > I watched OU programs as a child too :-) > I didn't, my parents would never have a TV. ::) I got that from a book, The World's Worst Aircraft. > I suggest you consider why you are moving directories about, I have just got > out of the habit. > Basicially I put a bit more thought up-front as to where I want to put stuff > and then put it there. Sure. Let me get a modest little cybernetic interface to one of those temporal vision thingummabobs they have these days and I'll call you right back. Sorry if that was a bit harsh, but I've had far too much 'advice' to 'just do this easy little thing'... Computers are supposed to supplement the brain, to help, not require more (and in some cases quite impossible) work. To file anything so you can find it again requires experience in filing that particular information type. I'm constantly dealing with new data... -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] first timer - editing plan9.ini
On Sun, Jul 19, 2009 at 7:12 PM, Skip Tavakkolian <9...@9netics.com> wrote: > > The few minutes spent learning ed(1) will be well repaid. You'll be > > one of the smartest guys on your block. > > i second that. learning it has been one of the best investments of my > time since 1982. > > > ed is a life saver when other stuff just won't fit :-). Also ed "scripts" can be quite handy to have around indeed.
Re: [9fans] dcp - a deep copy script, better than dircp
> ...c-stoff/t-stoff powered rocket... I watched OU programs as a child too :-) I suggest you consider why you are moving directories about, I have just got out of the habit. If I get a tar or a zip which contains dome data I need I just mount it with fs/tarfs or fs/zipfs and look inside. If I want just a few files I cp them to $home, if I want most of it then I extract the image to the destination where it is needed. Basicially I put a bit more thought up-front as to where I want to put stuff and then put it there. If you want dircp as a backup mechnism then can I suggest either fossil and venti, or, mk9660(8). mk9660 creates a dump-like heirarchy in a single ISO image, mergeing multiple dumps into the single ISO, stripping dumplicate files as it goes; kudos to wkj I believe. -Steve
Re: [9fans] dcp - a deep copy script, better than dircp
On Mon, 20 Jul 2009 07:50:08 -0400 erik quanstrom wrote: > > & [what] does mkext stand for), and > > make extract, i assume. > > > > > file /bin/mkfs > > /bin/mkfs: cannot open: '/bin/mkfs' file does not exist > > > > Dude, like, huh? > > you must have missed the first few lines of the man page > > disk/mkfs [-aprvxU] [-d root] [-n name] [-s source] [-u > users] [-z n] proto ... > > disk/mkext [-d name] [-u] [-h] [-v] [-x] [-T] file ... > > this means mkfs is in /bin/disk plan 9 uses subdirectories > in /bin. actually in the fs, mkfs is in the directory > /$objtype/bin/disk/ Ah, cheers. I do rather feel like I've been recommended to use a c-stoff/t-stoff powered rocket hopper where a family car would suffice though. -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] strange behaviour of ps under load
On Mon Jul 20 04:11:39 EDT 2009, gd...@9grid.es wrote: > hello > > today i found 9grid plan9 under heavy load, stats reports load ~2000, syscall > ~6, context ~22000, i was trying to discover which proc has gone crazy, > but i can't even complete a ps. I can do other operations, such as sending > this email over drawterm, run stats, netstat, read the logs, etc. but i can't > run ps, or any other /proc related tool, i can't kill/Kill/slay anything. > > I can ls /proc > > cpu% ls -l | wc -l > 573 i've seen this problem before, without an unreasonable load. it happened on a dual-processor machine. since procopen() requires p->debug, it stands to reason that somebody's got p->debug qlocked and won't let go. this is an old problem. here are russ' thoughts from 7 years ago. http://9fans.net/archive/2002/02/350 http://9fans.net/archive/2002/02/360 - erik
Re: [9fans] Question about Plan9 project
it is so difficult to 'fork' the project that it took me less than 10 minutes to turn the kernel sources into a hg repository. On Sat, Jul 18, 2009 at 2:59 PM, ron minnich wrote: > On Sat, Jul 18, 2009 at 9:59 AM, Uriel wrote: > >> Plan 9 is *not* an open source project, it can hardly be called a >> project even: There is no release management, there is no development >> process, there is no way to know what anyone is working on, no way to >> have any idea of what changes and features to expect in the future or >> when, or when any given bug might be fixed, or even a bug database for >> that matter, > > > This is an interesting statement and should be revised. So let's correct it. > > Take that above text and add this, please: > "That is visible to Uriel, or that will ever be visible to Uriel, or > that Uriel has any possibility of influencing, given that Uriel has > burned every last bridge he might have ever had with the Plan 9 > developers to the ground.". > >> So you are on your own, you can take the code (while the site happens >> to be up, or from a mirror), do whatever you like with it, but that is >> all there is and all anyone can count on. > > So, let's revise this one too.. > > "I, Uriel, taking up Noah Evans offer, will be forking the code base > and releasing an OS called Plan-U. I will provide servers that resolve > all the problems seen with the bell labs server, and I will take on > the task, with my friends, of providing all the things I see lacking > in the current setup. It's much easier to contribute a solution than > complain, and I am not the type who gets perverse joy out of just > complaining and yelling at people on a mailing list. That game is for > losers. Rather, I wish to provide a constructive solution, and I know > that after a few months people will ignore the bell labs site and > flock to mine. It worked for openbsd, and it can work for Plan U. As > part of this effort, I hereby unsubscribe from this list, and am > starting a new one called ufans for my new OS release. Please join me > in this important work. " > > There now, wouldn't that be much easier? You already run a bunch of > servers; I think you could pull it off. And it might lower your blood > pressure :-) > > You declined Noah's serious offer to take over sources; here's another > chance! Go for ti! You should not assume it would not work. > > Ron > >
Re: [9fans] dcp - a deep copy script, better than dircp
> & [what] does mkext stand for), and make extract, i assume. > > file /bin/mkfs > /bin/mkfs: cannot open: '/bin/mkfs' file does not exist > > Dude, like, huh? you must have missed the first few lines of the man page disk/mkfs [-aprvxU] [-d root] [-n name] [-s source] [-u users] [-z n] proto ... disk/mkext [-d name] [-u] [-h] [-v] [-x] [-T] file ... this means mkfs is in /bin/disk plan 9 uses subdirectories in /bin. actually in the fs, mkfs is in the directory /$objtype/bin/disk/ - erik
Re: [9fans] dcp - a deep copy script, better than dircp
On Mon, 20 Jul 2009 10:55:21 +0100 Charles Forsyth wrote: > >Before I say anythign daft, what's '+'? It does not appear to be special on > >my system. > > it's interpreted by mkfs in its proto file to mean all the substructure of a > directory. > see mkfs(8). > Thanks. I looked over the man page last night & somehow missed the "Mkfs copies only those files that are out of date" part. Ah... that part would be more relevant to cej than me. I'm primarily concerned with moving dirs and I already know what tar does. Mkfs seemed very confusing at first, it's confusingly-named for one thing (it does not make filesystems & wtf does mkext stand for), and IMHO default destinations belong in a script, not a compiled binary. Also I'm absurdly pleased with how terse dcp is. Apart from the option check there are 4 lines of code. :) I have half a mind to write a new script using mkfs to get the functionality cej would like, but: file /bin/mkfs /bin/mkfs: cannot open: '/bin/mkfs' file does not exist Dude, like, huh? -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] dcp - a deep copy script, better than dircp
On Mon, 20 Jul 2009 11:32:11 +0200 wrote: > hi, > > i'm quite happy with the 'cpdir' by Kenji Arisawa (thanks, Kenji!) on > sources/contrib/arisawa. > However, your scripty seems fine, too. Could we add a switch to conform with > gnu's cp -au? Just not to overwrite newer files. I don't know there is an > option there in 'tar' (I can't see in in tar(1)). At least we have the 'k' > modifier, which could help. Tar's -k modifier is the nearest I can find. Mkext has no such option and I've found no cpio (thankfully?). I don't know where to look for or suggest such an option. It may seem natural in tar, but there's a danger with archive utilities that their feature list may grow well beyond a comfortable size for the ordinary user. Also a copy which omits files would be much faster if it did not read the files which it is going to omit, which rather rules out archive_util | archive_util usage. I think the option would be better added to arisawa's cpdir, but I'm too lazy. :) -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] i/o on a hangup channel asymmetry
>pipe would return -1 (and set a error condition) and the >applications were paying attention (and I'm pretty sure all >applications on Plan 9 would do a reasonable thing when >presented with -1 from a write). they only notice when the write occurs. suppose that takes several minutes of computation.
Re: [9fans] dcp - a deep copy script, better than dircp
hi, i'm quite happy with the 'cpdir' by Kenji Arisawa (thanks, Kenji!) on sources/contrib/arisawa. However, your scripty seems fine, too. Could we add a switch to conform with gnu's cp -au? Just not to overwrite newer files. I don't know there is an option there in 'tar' (I can't see in in tar(1)). At least we have the 'k' modifier, which could help. Regards, ++pac. <>
Re: [9fans] dcp - a deep copy script, better than dircp
>Before I say anythign daft, what's '+'? It does not appear to be special on my >system. it's interpreted by mkfs in its proto file to mean all the substructure of a directory. see mkfs(8).
Re: [9fans] i/o on a hangup channel asymmetry
you don't really want to get "write error" printed from every process in a pipe line such as slowly-compute-big-file | dosomemore | andyetmore | sed -n '/something/;p;q' or even slowly-compute-big-file | badusageofsomething where the latter prints a "usage" message and quits. you want to make sure the previous commands in the pipeline stop, right away. (they might be in a script. they might even be costing money.) actually, if i were looking for something exceptional to fix, i'd get linux and the BSDs to stop thinking they still need character and block "special files" as special types of files in a physical file system, to represent devices.--- Begin Message --- On Jul 19, 2009, at 2:55 PM, Charles Forsyth wrote: not for network connections? i think pipe is the only case, and even that is suppressed for pipes that carry 9p, after mounting. one last kick of a dead horse: see that's exactly what I'm talking about -- all these exceptions and for what? I'm pretty sure if we change the devpipe today not to send a note nobody would even notice... Thanks, Roman.--- End Message ---
[9fans] strange behaviour of ps under load
hello
today i found 9grid plan9 under heavy load, stats reports load ~2000, syscall
~6, context ~22000, i was trying to discover which proc has gone crazy, but
i can't even complete a ps. I can do other operations, such as sending this
email over drawterm, run stats, netstat, read the logs, etc. but i can't run
ps, or any other /proc related tool, i can't kill/Kill/slay anything.
I can ls /proc
cpu% ls -l | wc -l
573
something like
cpu% for(i in `{ls}) {echo -n 'PID ' $i 'has status. . . '; cat $i/status | wc
-c }
[]
PID 1944693 has status. . . 176
PID 1944698 has status. . . 176
PID 1944699 has status. . . 176
PID 1944700 has status. . . 176
PID 1944707 has status. . .
and here ends, i can't know which process is that nor kill it.
I can ls it:
cpu% ls -l /proc/1944707/
--rw-rw p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/args
--rw-r- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/ctl
--r--r--r-- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/fd
--rw-r- p 0 offending_user bootes 108 Dec 1 2008 /proc/1944707/fpregs
--r--r- p 0 offending_user bootes 76 Dec 1 2008 /proc/1944707/kregs
--rw-r- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/mem
--rw-r- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/note
--rw-rw-r-- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/noteid
--rw-r- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/notepg
--r--r--r-- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/ns
--r--r- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/proc
--r--r- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/profile
--rw-r- p 0 offending_user bootes 76 Dec 1 2008 /proc/1944707/regs
--r--r--r-- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/segment
--r--r--r-- p 0 offending_user bootes 176 Dec 1 2008 /proc/1944707/status
--rw-r- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/text
--r--r- p 0 offending_user bootes 0 Dec 1 2008 /proc/1944707/wait
i can't either chmod those files. (is that date normal? seems all /proc is
with that date :?)
any tip on how to solve this without rebooting?
thanks!!
gabi
Re: [9fans] new usb stack and implicit timeouts
On Sun, Jul 19, 2009 at 5:58 PM, Francisco J Ballesteros wrote: > On Sun, Jul 19, 2009 at 5:46 PM, wrote: >> http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket >> > > IIRC, I think the host controller is responsible for timing out > requests sent to the device (I refer to setup packets), but my uchi > does not. In any case, I don't think anyone wants to remove timeouts > from ctl requests. > > I am unsure I would remove timeouts even from bulk endpoints. It is true that some devices (the usb/serial for example) need to read for an undefined time waiting for data, but I don't think that is an issue as long as the timeouts are long enough, doing polling is quite easy. There is polling in the lower levels anyway. On the other hand, I think smart card readers go for lunch on a read and may never come back if there is no timeout. Of course alarm() can be used, but a timeout makes it simpler. I prefer having to poll on some cases than having to use signals on others. -- - curiosity sKilled the cat
