Re: [9fans] boot 9vx from Plan 9 cpu/fileserver
http://groups.google.com/group/comp.os.plan9/browse_thread/thread/3df541c516a79daa/6ad1abca006414d4?lnk=gstq=mount+9vx+root+from+fileserver#6ad1abca006414d4 Moin, how do I have to call 9vx to get the root from a remote Plan 9 cpu/filserver? Matthias
Re: [9fans] Why do we need syspipe() ?
the example that prompted the `fish' remark was: cd location; pwd shows location.
Re: [9fans] RFNOMNT and/or least privilege
On Wed, Jan 7, 2009 at 3:24 PM, Dave Eckhardt davide...@cs.cmu.edu wrote: The web server infrastructure seems pretty focused on running as user none, which makes sense as far as it goes, but I don't want none to be able to read the files served by the web servers because anybody who can log in to the machine can become none. Pegasus[1] is different here, it has namespace seperation between virtual servers which run as arbitrary users. I can't really comment on other differences, as I'm not very familiar with httpd. Or pegasus, for that matter ;) I just read the intro the other day and it sounds like something you might be interested in. [1] http://plan9.aichi-u.ac.jp/pegasus/ -sqweek
Re: [9fans] directly opening Plan9 devices
The underlying assumption of motivation for this discussion is that jailing (or whatever we want to call it) is somehow a good thing. Given that every CPU we care about comes with virtualization hardware, I just can't see the point of jails -- seems like an idea whose time has gone, kind of like 8086 segments. If we give up on using RFNOMNT as a jailing mechanism, do the concerns really make any sense? ron
Re: [9fans] directly opening Plan9 devices
On Wed Jan 7 11:58:04 EST 2009, rminn...@gmail.com wrote: The underlying assumption of motivation for this discussion is that jailing (or whatever we want to call it) is somehow a good thing. Given that every CPU we care about comes with virtualization hardware, I just can't see the point of jails -- seems like an idea whose time has gone, kind of like 8086 segments. If we give up on using RFNOMNT as a jailing mechanism, do the concerns really make any sense? ron arm has virtualization? - erik
[9fans] Sources vac scores?
Is the venti backing sources publically readable? Perhaps equally importantly, are the scores of sources dump published anywhere? I ask because I'd like a local copy of the development history, and while I am currently spidering sources' dump, that's going to take a long while and venti/copy -f seems like it'd be a much better option (and nicer to Bell Labs' bandwidth, at that). :) Thanks. --nwf; pgpJw0cCFaDdz.pgp Description: PGP signature
[9fans] venti icachewriteproc going past isect
hi, i've had this behavior some time ago and haven't solved that, and now Akshat Kumar is experiencing exactly the same, but as the venti at faul is running on his mail server, he's unable to post here. as soon as venti starts, an icachewriteproc can be observed which produces high load, making the whole system unresponsive: bootes 130:00 0:2742392K Pwrite venti [icachewriteproc:/dev/sdC0/isect] from /proc/13/fd it can be seen that its offset into /dev/sdC0/isect keeps increasing, even past the partition size: % ls -l /dev/sdC0/isect --rw-r- S 0 bootes bootes 3175279616 Aug 22 23:38 /dev/sdC0/isect % cat /proc/13/fd 8 rw S0 (04300066 1 00) 0 3223880192 /dev/sdC0/isect this always reproduces after a restart. killing icachewriteproc renders fossil unresponsive, essentially making system unusable. fshalt -r hangs at 'syncing.../srv/fscons...', so the machine can't be rebooted cleanly. any hints? thanks, oleg
Re: [9fans] Changelogs Patches?
On Tue, 2009-01-06 at 18:44 -0500, erik quanstrom wrote:
a big difference between the decisions is in data integrety.
it's much easier to break a fs that rewrites than it is a
worm-based fs.
True. But there's a grey area here: an FS that *never* rewrites
live blocks, but can reclaim dead ones. That's essentially
what ZFS does.
unfortunately, i would think that can result in data loss since
i can can no longer take a set of copies of the fs {fs_0, ... fs_n}
and create a new copy with all the data possibly recovered
by picking a set good blocks from the fs_i, since i can make
a block dead by removing the file using it and i can make it
live again by writing a new file.
perhaps i've misinterpreted what you are saying?
Lets see. May be its my misinterpretation of what venti does. But so
far I understand that it boils down to: I give venti a block of any
length, it gives me a score back. Now internally, venti might decide
to split that huge block into a series of smaller ones and store it
as a tree. But still all I get back is a single score. I don't care
whether that score really describes my raw data block, or a block full
of scores that actually describe raw data. All I care is that when
I give venti that score back -- it'll reconstruct the data. I also
have a guarantee that the data will never ever be deleted.
Now, because of that guarantee (blocks are never deleted) and since
all blocks bigger than 56k get split venti has a nice property of
reusing blocks from existing trees. This happens as a by-product
of the design: I ask venti to store a block and if that same block
was already there -- there will be an extra arrow pointing at it.
All in all -- very compact way of representing a forest of trees.
Each tree corresponds to a VtEntry data structure and blocks full
of VtEntry structures are called VtEntryDir's. Finally a root
VtEntryDir is pointed at by VtRoot structure.
Contrast this with ZFS, where blocks are *not* addressed via scores,
but rather with a vdev:offset pairs called DVAs. This, of course,
means that there's no block coalescing going on. You ask ZFS to store
a block it gives you a DVA back. You ask it to store the same block
again, you get a different DVA (well, actually it gives you a block
pointer which is DVA augmented by extra stuff).
That fundamental property of ZFS makes it impossible to have a
single block implicitly referenced by multiple trees, unless the
block happens to be part of an explicit snapshot of the same object
at some later point in time.
Thus, when there's a need to modify an existing object, ZFS never
touches the old blocks. It build a tree of blocks, *explicitly*
reusing those blocks that haven't changed. When it is done building
the new tree the old one is still the active one. The last transaction
that happens updates an uberblock (ZFS speak for VtRoot) in an atomic
fashion, thus making a new tree an active one. The old tree is still
around at that point and if it is not part of a snapshot it can be
garbage collected and the blocks can be freed if it is part of the
snapshot -- it is preserved. In the later case the behavior seems
to be exactly what venti does
But even in the former case I don't see how the corruption could be
possible. Please elaborate.
Thanks,
Roman.
Re: [9fans] Changelogs Patches?
Lets see. May be its my misinterpretation of what venti does. But so far I understand that it boils down to: I give venti a block of any length, it gives me a score back. Now internally, venti might decide just a clarification. this is done by the client. from venti(6): Files and Directories Venti accepts blocks up to 56 kilobytes in size. By conven- tion, Venti clients use hash trees of blocks to represent arbitrary-size data files. [...] But even in the former case I don't see how the corruption could be possible. Please elaborate. i didn't say there would be corruption. i assumed corruption and outlined how one could recover the maximal set of data and have a consistent fs (assuming the damage doesn't cut a full strip across all backups) by simply picking a good block at each lba from the available damaged and/or incomplete backups, which may originate at different times. (russ was the first that i know of to put this into practice.) in the case of zfs, my claim is that since zfs can reuse blocks, two vdev backups, each with corruption or missing data in different places are pretty well useless. - erik
Re: [9fans] Sources vac scores?
No, we don't publish venti scores; that would be very poor security practice. We'll soon be announcing a way to mirror sources with replica, once we've shaken the procedure down. We will then discourage the existing mirroring schemes.
Re: [9fans] Sources vac scores?
On Wed, Jan 07, 2009 at 08:37:02PM -0500, ge...@plan9.bell-labs.com wrote: No, we don't publish venti scores; that would be very poor security practice. In the general case, yes, absolutely. In the case of the nightly scores for sources/plan9, is it still? AFAICT the entire directory tree there is world readable by design... if this isn't the case, please say so and I'll just go back to spidering. Speaking of spidering, it looks like it's about 120MB/day worth of bandwidth to just point vac at /n/sourcesdump/$YEAR/$DUMP and have it go. For various reasons, it looks like my connection is able to spider each day in about 45 minutes to an hour (this is going to take a while...). I'm sure JHU won't mind the traffic; will the Labs? We'll soon be announcing a way to mirror sources with replica, once we've shaken the procedure down. We will then discourage the existing mirroring schemes. Will this procedure include the history or just the current version? --nwf; pgpirkLeXZYzf.pgp Description: PGP signature
[9fans] cheap, low-resolution terminal
http://csplan9.rit.edu/users/john/plan9vt220-full.jpeg http://csplan9.rit.edu/users/john/plan9vt220-screen.jpeg Just threw this onto my CPU server (yes, mock my slow processor, it was free) and was once again pleased with how easy it is to set stuff up on Plan 9. Just one line in plan9.ini and I was rocking. John Floren
Re: [9fans] cheap, low-resolution terminal
On Wed, Jan 7, 2009 at 7:10 PM, j...@csplan9.rit.edu wrote: http://csplan9.rit.edu/users/john/plan9vt220-full.jpeg http://csplan9.rit.edu/users/john/plan9vt220-screen.jpeg Just threw this onto my CPU server (yes, mock my slow processor, it was free) and was once again pleased with how easy it is to set stuff up on Plan 9. Just one line in plan9.ini and I was rocking. Love the green phosphor. Is it persistent? :-) ron
Re: [9fans] cheap, low-resolution terminal
On Wed, Jan 7, 2009 at 7:10 PM, j...@csplan9.rit.edu wrote: http://csplan9.rit.edu/users/john/plan9vt220-full.jpeg http://csplan9.rit.edu/users/john/plan9vt220-screen.jpeg Just threw this onto my CPU server (yes, mock my slow processor, it was free) and was once again pleased with how easy it is to set stuff up on Plan 9. Just one line in plan9.ini and I was rocking. Love the green phosphor. Is it persistent? :-) ron Yeah, it's pretty persistent. Also, the green phosphor has a lovely tendency to make everything look purple after you've been working with the terminal for about half an hour. I only wish the ADM-3A didn't make that high-pitched whining noise (flyback problem, apparently), because it looks even cooler and has a very good UNIX keyboard. I guess I'll have to wait until I get older and can't hear such high frequencies any more. John Floren
Re: [9fans] directly opening Plan9 devices
On Wed, Jan 7, 2009 at 9:16 AM, erik quanstrom quans...@coraid.com wrote: On Wed Jan 7 11:58:04 EST 2009, rminn...@gmail.com wrote: The underlying assumption of motivation for this discussion is that jailing (or whatever we want to call it) is somehow a good thing. Given that every CPU we care about comes with virtualization hardware, I just can't see the point of jails -- seems like an idea whose time has gone, kind of like 8086 segments. If we give up on using RFNOMNT as a jailing mechanism, do the concerns really make any sense? ron arm has virtualization? Some do. ARMs are so cheap ... don't jail things, just get another one. ron
Re: [9fans] cheap, low-resolution terminal
Just one line in plan9.ini and I was rocking. I'll have to break out my amber-screen vt420 and give it a try. Probably not terribly useful w/o a mouse, though! :) winmail.dat
Re: [9fans] cheap, low-resolution terminal
Just one line in plan9.ini and I was rocking. I'll have to break out my amber-screen vt420 and give it a try. Probably not terribly useful w/o a mouse, though! :) If somebody (not necessarily me) was to put interrupt functionality into rc, you could basically experience 70s UNIX again--assuming you are happy using ed. I'd try putting in the interrupt thing, but I expect it would require removing the functionality from rio, which I don't care to do :) John
Re: [9fans] cheap, low-resolution terminal
Just one line in plan9.ini and I was rocking. I'll have to break out my amber-screen vt420 and give it a try. Probably not terribly useful w/o a mouse, though! :) But it's not bad as the console of a file server. My vt220 is on an RS232 switch so it can be the console of a couple of machines. BLS
