* Re: [9fans] 4th edition file server available
@ 2003-01-08 8:13 okamoto
2003-01-08 16:56 ` Russ Cox
0 siblings, 1 reply; 32+ messages in thread
From: okamoto @ 2003-01-08 8:13 UTC (permalink / raw)
To: 9fans
> there are many other differences. It is a user-level
> program rather than a special kernel, it speaks 9P2000
> (and not 9P1), and there are numerous other improvements,
> including enormous file names and also soft updates so that
> the disk image is always in a consistent state.
Does this mean we don't need il protocol anymore?
Kenji
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
@ 2003-02-10 21:06 Andrey S. Kukhar
0 siblings, 0 replies; 32+ messages in thread
From: Andrey S. Kukhar @ 2003-02-10 21:06 UTC (permalink / raw)
To: 9fans
I wonder, fossil, why so geological name?
-kyxap
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
@ 2003-01-14 19:13 Russ Cox
0 siblings, 0 replies; 32+ messages in thread
From: Russ Cox @ 2003-01-14 19:13 UTC (permalink / raw)
To: 9fans
g% pull
c sys/src/cmd/cpu.c
c 386/bin/cpu
g%
g% cpu -h `{perl -e 'print "a"x1000'}
cpu: can't dial: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaa: cs: can't translate address
g%
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
@ 2003-01-14 18:23 Skip Tavakkolian
0 siblings, 0 replies; 32+ messages in thread
From: Skip Tavakkolian @ 2003-01-14 18:23 UTC (permalink / raw)
To: 9fans
> It has both the letters f and s in it, was in out dictionary,
> and has a feel of permanence.
It is efficient by being skeletal?
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
@ 2003-01-14 6:06 okamoto
2003-01-14 13:55 ` David Presotto
2003-02-14 16:04 ` Andrey S. Kukhar
0 siblings, 2 replies; 32+ messages in thread
From: okamoto @ 2003-01-14 6:06 UTC (permalink / raw)
To: 9fans
> I wonder, fossil, why so geological name?
From a view point of geologist, I suppose fossil is not so 'geologic'
name. ?
Kenji
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-14 6:06 okamoto
@ 2003-01-14 13:55 ` David Presotto
2003-02-14 16:04 ` Andrey S. Kukhar
1 sibling, 0 replies; 32+ messages in thread
From: David Presotto @ 2003-01-14 13:55 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 92 bytes --]
It has both the letters f and s in it, was in out dictionary,
and has a feel of permanence.
[-- Attachment #2: Type: message/rfc822, Size: 1415 bytes --]
From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Tue, 14 Jan 2003 15:06:04 +0900
Message-ID: <e5fcb3c136701335102b6f15dc0c2525@granite.cias.osakafu-u.ac.jp>
> I wonder, fossil, why so geological name?
From a view point of geologist, I suppose fossil is not so 'geologic'
name. ?
Kenji
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-14 6:06 okamoto
2003-01-14 13:55 ` David Presotto
@ 2003-02-14 16:04 ` Andrey S. Kukhar
1 sibling, 0 replies; 32+ messages in thread
From: Andrey S. Kukhar @ 2003-02-14 16:04 UTC (permalink / raw)
To: 9fans
dictionary-translator said me that this is geologic
word (e.g., in expression ``useful fossils'').
It`s not right?
-kyxap
> From a view point of geologist, I suppose fossil is not
> so 'geologic' name. ?
>
> Kenji
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
@ 2003-01-13 10:01 Richard Miller
2003-01-13 17:13 ` Russ Cox
2003-01-13 17:19 ` rob pike, esq.
0 siblings, 2 replies; 32+ messages in thread
From: Richard Miller @ 2003-01-13 10:01 UTC (permalink / raw)
To: 9fans
> One advantage (as I understood it) of using a specialized kernel
> was a form of security -- there were *no* user mode programs
> whose bugs could be exploited.
It went further than that: you couldn't even exploit a buffer overflow
to exec a shell, because there was no shell and no exec.
Would it be feasible, as part of bootstrapping a minimal fossil
server, to remove or otherwise disable the exec system call
once everything was running?
-- Richard
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-13 10:01 Richard Miller
@ 2003-01-13 17:13 ` Russ Cox
2003-01-14 15:20 ` andrey mirtchovski
2003-01-13 17:19 ` rob pike, esq.
1 sibling, 1 reply; 32+ messages in thread
From: Russ Cox @ 2003-01-13 17:13 UTC (permalink / raw)
To: 9fans
> Would it be feasible, as part of bootstrapping a minimal fossil
> server, to remove or otherwise disable the exec system call
> once everything was running?
Of course. Go ahead if you really want. I don't want to live
in that environment. There are no buffer overflows anyway. ;-)
I _really_ like the fact that I can run other programs on
the file server now, like flchk. I'm not going back.
I think it's reasonable not to run any services on the
machine other than fossil, and to connect with a serial
console to run other things. Disabling exec strikes me
as extreme.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-13 17:13 ` Russ Cox
@ 2003-01-14 15:20 ` andrey mirtchovski
2003-01-14 18:55 ` Scott Schwartz
0 siblings, 1 reply; 32+ messages in thread
From: andrey mirtchovski @ 2003-01-14 15:20 UTC (permalink / raw)
To: 9fans
On Mon, 13 Jan 2003, Russ Cox wrote:
> There are no buffer overflows anyway. ;-)
I see the smiley, but have to reply anyway. this is not a nasty jab
at Russ, just a fix (I hope :)
there's a buffer overflow in cpu.c (strcpy):
% cpu -h `{perl -e '{print "A"x100;}'}
cpu 116986: suicide: sys: trap: fault read addr=0x19000 pc=0x00005b8b
plan9% acid 116986
/proc/116986/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: stk()
At pc:0x00005b8b:fmtfmt+0x1f /sys/src/libc/fmt/fmt.c:63
fmtfmt(c=0x00000073) /sys/src/libc/fmt/fmt.c:57
called from _fmtdispatch+0x83 /sys/src/libc/fmt/fmt.c:175
_fmtdispatch(isrunes=0x00000000,f=0x7fffeb48,fmt=0x000168b6) /sys/src/libc/fmt/fmt.c:113
called from dofmt+0x75 /sys/src/libc/fmt/dofmt.c:62
dofmt(fmt=0x000168b4,f=0x7fffeb48) /sys/src/libc/fmt/dofmt.c:7
called from vsnprint+0x62 /sys/src/libc/fmt/vsnprint.c:20
vsnprint(len=0x00000100,buf=0x00018734,args=0x7fffebac,fmt=0x000168b0) /sys/src/libc/fmt/vsnprint.c:5
called from snprint+0x2b /sys/src/libc/fmt/snprint.c:13
snprint(fmt=0x000168b0,buf=0x00018734,len=0x00000100) /sys/src/libc/fmt/snprint.c:5
called from netmkaddr+0x5e /sys/src/libc/port/netmkaddr.c:34
netmkaddr(linear=0x00017e0c,defnet=0x00000000,defsrv=0x00016978) /sys/src/libc/port/netmkaddr.c:10
called from rexcall+0x28 /sys/src/cmd/cpu.c:347
rexcall(host=0x00017e0c,service=0x00016978,fd=0x7fffed98) /sys/src/cmd/cpu.c:339
called from main+0x132 /sys/src/cmd/cpu.c:147
main(argv=0x7fffef84,argc=0x00000000) /sys/src/cmd/cpu.c:77
called from _main+0x31 /sys/src/libc/386/main9.s:16
acid:
----------------------
here's the fix:
plan9% diff cpu.c /sys/src/cmd/cpu.c
121c121
< strncpy(system, p, sizeof system);
---
> strcpy(system, p);
plan9% 8c cpu.c; 8l cpu.8
plan9% 8.out -h `{perl -e '{print "A"x100}'}
cpu: can't dial: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA: cs: can't translate address
plan9%
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-14 15:20 ` andrey mirtchovski
@ 2003-01-14 18:55 ` Scott Schwartz
2003-01-14 19:11 ` andrey mirtchovski
0 siblings, 1 reply; 32+ messages in thread
From: Scott Schwartz @ 2003-01-14 18:55 UTC (permalink / raw)
To: 9fans
Andrey writes:
| < strncpy(system, p, sizeof system);
That still has the problem that strncpy is not required to NUL terminate
the destination. How about strecpy?
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-14 18:55 ` Scott Schwartz
@ 2003-01-14 19:11 ` andrey mirtchovski
2003-01-14 19:18 ` andrey mirtchovski
2003-01-14 19:28 ` Russ Cox
0 siblings, 2 replies; 32+ messages in thread
From: andrey mirtchovski @ 2003-01-14 19:11 UTC (permalink / raw)
To: 9fans
I agree, this opens up a whole new can of worms, as illustrated here:
Miller, T. C., Raadt, T. D.
strlcpy and strlcat -- Consistent, Safe, String Copy and Concatenation.
Proceedings of USENIX Annual Technical Conference. June,
1999. http://www.openbsd.org/papers/strlcpy-paper.ps
on the other hand I think we're in the unique position to fix strncpy
instead of adding another syscall -- after all it's not Ken C we're
dealing with :)
andrey
On Tue, 14 Jan 2003, Scott Schwartz wrote:
> Andrey writes:
> | < strncpy(system, p, sizeof system);
>
> That still has the problem that strncpy is not required to NUL terminate
> the destination. How about strecpy?
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-13 10:01 Richard Miller
2003-01-13 17:13 ` Russ Cox
@ 2003-01-13 17:19 ` rob pike, esq.
1 sibling, 0 replies; 32+ messages in thread
From: rob pike, esq. @ 2003-01-13 17:19 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 135 bytes --]
A less drastic step would be to disable network ports such as
cpu and telnet, to require people to use the console to debug.
-rob
[-- Attachment #2: Type: message/rfc822, Size: 1972 bytes --]
From: Richard Miller <miller@hamnavoe.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Mon, 13 Jan 2003 10:01:30 0000
Message-ID: <14897aa3a24d632f340f30863deb7850@hamnavoe.demon.co.uk>
> One advantage (as I understood it) of using a specialized kernel
> was a form of security -- there were *no* user mode programs
> whose bugs could be exploited.
It went further than that: you couldn't even exploit a buffer overflow
to exec a shell, because there was no shell and no exec.
Would it be feasible, as part of bootstrapping a minimal fossil
server, to remove or otherwise disable the exec system call
once everything was running?
-- Richard
^ permalink raw reply [flat|nested] 32+ messages in thread
* [9fans] 4th edition file server available
@ 2003-01-12 2:36 Joel Salomon
2003-01-12 3:10 ` jmk
0 siblings, 1 reply; 32+ messages in thread
From: Joel Salomon @ 2003-01-12 2:36 UTC (permalink / raw)
To: 9fans
>It is a user-level program rather than a special kernel
One advantage (as I understood it) of using a specialized kernel was a form of security -- there were *no* user mode programs whose bugs could be exploited. How "standalone" can a Fossil/Venti server be? Can I delete almost everything in /bin to "lock down" the system?
--Joel
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-12 2:36 Joel Salomon
@ 2003-01-12 3:10 ` jmk
0 siblings, 0 replies; 32+ messages in thread
From: jmk @ 2003-01-12 3:10 UTC (permalink / raw)
To: 9fans
On Sat Jan 11 21:37:18 EST 2003, joelcsalomon@excite.com wrote:
>
> >It is a user-level program rather than a special kernel
> One advantage (as I understood it) of using a specialized kernel was a form of security -- there were *no* user mode programs whose bugs could be exploited. How "standalone" can a Fossil/Venti server be? Can I delete almost everything in /bin to "lock down" the system?
>
> --Joel
The intent is that it should be possible to configure the system
via the kernel config such that the only process(es) running are
those necessary to run a fileserver, i.e. fossil and factotum, with
only a physical console for control. The less paranoid you are, the
more user level stuff you can leave running, e.g. starting fossil
from /bin/cpurc.
Of course, we're nowhere near there yet.
--jim
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
@ 2003-01-09 13:44 rog
2003-01-09 14:39 ` Russ Cox
0 siblings, 1 reply; 32+ messages in thread
From: rog @ 2003-01-09 13:44 UTC (permalink / raw)
To: 9fans
> /sys/doc/fossil.pdf mentions an ``experimental file stack device'' devfs(3).
> I'm just curious; is that man page available?
> (could not find on plan9 web nor on sources)
it's a mistake in the paper.
see instead fs(3).
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
@ 2003-01-08 7:18 Skip Tavakkolian
0 siblings, 0 replies; 32+ messages in thread
From: Skip Tavakkolian @ 2003-01-08 7:18 UTC (permalink / raw)
To: 9fans
> there are numerous other improvements,
> including enormous file names
> g% x=`{perl -e 'print "a"x2000'}
> g% >$x
> g% ls -l $x
This is a new challenge to people coming up with class names (and depth)
for Java.
^ permalink raw reply [flat|nested] 32+ messages in thread
* [9fans] 4th edition file server available
@ 2003-01-08 6:45 Russ Cox
2003-01-08 11:09 ` Axel Belinfante
` (3 more replies)
0 siblings, 4 replies; 32+ messages in thread
From: Russ Cox @ 2003-01-08 6:45 UTC (permalink / raw)
To: 9fans
The new 4th edition file server, named Fossil,
is now available on sources. There are some
how-to docs for setting up Venti and Fossil at:
http://plan9.bell-labs.com/wiki/plan9/setting_up_venti
http://plan9.bell-labs.com/wiki/plan9/setting_up_fossil
The man pages fossil(4) and fossilcons(8) are
the definitive reference. /sys/doc/fossil.pdf (aka
http://plan9.bell-labs.com/sys/doc/fossil.pdf)
describes the disk structures and also the Vac
structures for those interested in hacking the
internals.
Conceptually, Fossil is similar to the current file server
with Venti instead of a WORM juke box, but practically
there are many other differences. It is a user-level
program rather than a special kernel, it speaks 9P2000
(and not 9P1), and there are numerous other improvements,
including enormous file names and also soft updates so that
the disk image is always in a consistent state.
It is still a work in progress, but it's ready to be used
by those feeling adventurous.
Enjoy.
Sean, Jim, Russ
g% x=`{perl -e 'print "a"x2000'}
g% >$x
g% ls -l $x
--rw-rw-r-- M 8 rsc rsc 0 Jan 8 01:30 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
g%
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-08 6:45 Russ Cox
@ 2003-01-08 11:09 ` Axel Belinfante
2003-01-08 15:57 ` Fco.J.Ballesteros
2003-01-08 15:56 ` andrey mirtchovski
` (2 subsequent siblings)
3 siblings, 1 reply; 32+ messages in thread
From: Axel Belinfante @ 2003-01-08 11:09 UTC (permalink / raw)
To: 9fans
Congratulations!
I feel a bit adventurous -- but also in the need of
a little (or more?) hand-holding.
I have browsed through the setting up docs on wiki,
and a couple of the refered man pages, but
could not easily see how to build a fossil from
(to replace) an existing fake-worm file server,
taking into account the dump partition.
I recall reading before that at bell labs worm
disks of the fs were copied ``by hand'' one by one,
by taking them out of the fs.
Is there a way to transfer dump to fossil from
a running fake-worm fs (so, just using normal 9p
access, without going to the ``raw disks'')?
On a related note: my fake-worm fs uses relatively small
blocks (4Kb). Can I freely choose a block size for the
venti underlying the fossil, or should there be
a strict relation between the fake-worm block size
and the fossil/venti block size (e.g. due to transfer
of dump blocks)?
Thanks for any insight (pointers welcome),
Axel.
> The new 4th edition file server, named Fossil,
> is now available on sources. There are some
> how-to docs for setting up Venti and Fossil at:
[snip]
> It is still a work in progress, but it's ready to be used
> by those feeling adventurous.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-08 11:09 ` Axel Belinfante
@ 2003-01-08 15:57 ` Fco.J.Ballesteros
0 siblings, 0 replies; 32+ messages in thread
From: Fco.J.Ballesteros @ 2003-01-08 15:57 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
Not to fossil, but we're using this to move our worm into vac, which
can be serviced by venti. 9fs automates it for us.
#!/bin/rc
# mkvac: creates one vac archive. argument is day number.
#
srv -q il!sargazos.escet.urjc.es
mount /srv/il!sargazos.escet.urjc.es /n/dump dump
date
vname=`{echo $1 | sed 's|/|_|g'}
lname=`{cat mkvac.last}
echo vac -s -b16k -f dump/2002/$vname.vac -d dump/2002/$lname -q /n/dump/$1
time vac -s -b16k -f dump/2002/$vname.vac -d dump/2002/$lname -q /n/dump/$1
echo echo $vname.vac '>' mkvac.last
echo $vname.vac > mkvac.last
unmount /n/dump
rm /srv/il!sargazos.escet.urjc.es
date
This other one calls the previous one to automate it:
#!/bin/rc
days=(0508 0507 0506 .....other preferred days here)
for (d in $days) {
cp /dev/text /n/once/nemo/mkvacs.out
echo -n $d starts ' '
mkvac 2002/$d
echo
}
exit
We are doing 1.5 months per day or so.
[-- Attachment #2: Type: message/rfc822, Size: 3844 bytes --]
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Wed, 08 Jan 2003 12:09:07 +0100
Message-ID: <200301081109.h08B97629776@zamenhof.cs.utwente.nl>
Congratulations!
I feel a bit adventurous -- but also in the need of
a little (or more?) hand-holding.
I have browsed through the setting up docs on wiki,
and a couple of the refered man pages, but
could not easily see how to build a fossil from
(to replace) an existing fake-worm file server,
taking into account the dump partition.
I recall reading before that at bell labs worm
disks of the fs were copied ``by hand'' one by one,
by taking them out of the fs.
Is there a way to transfer dump to fossil from
a running fake-worm fs (so, just using normal 9p
access, without going to the ``raw disks'')?
On a related note: my fake-worm fs uses relatively small
blocks (4Kb). Can I freely choose a block size for the
venti underlying the fossil, or should there be
a strict relation between the fake-worm block size
and the fossil/venti block size (e.g. due to transfer
of dump blocks)?
Thanks for any insight (pointers welcome),
Axel.
> The new 4th edition file server, named Fossil,
> is now available on sources. There are some
> how-to docs for setting up Venti and Fossil at:
[snip]
> It is still a work in progress, but it's ready to be used
> by those feeling adventurous.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-08 6:45 Russ Cox
2003-01-08 11:09 ` Axel Belinfante
@ 2003-01-08 15:56 ` andrey mirtchovski
2003-01-08 16:53 ` Russ Cox
2003-01-08 22:52 ` Andrew
2003-01-09 13:16 ` Axel Belinfante
3 siblings, 1 reply; 32+ messages in thread
From: andrey mirtchovski @ 2003-01-08 15:56 UTC (permalink / raw)
To: 9fans
will you put a link to it on http://plan9.bell-labs.com/sys/doc/index.html
(the index page for Volume 2 documents) or it's not yet supposed to be
read by third parties?
thanx, andrey
On Wed, 8 Jan 2003, Russ Cox wrote:
> The man pages fossil(4) and fossilcons(8) are
> the definitive reference. /sys/doc/fossil.pdf (aka
> http://plan9.bell-labs.com/sys/doc/fossil.pdf)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-08 6:45 Russ Cox
2003-01-08 11:09 ` Axel Belinfante
2003-01-08 15:56 ` andrey mirtchovski
@ 2003-01-08 22:52 ` Andrew
2003-01-08 22:54 ` Russ Cox
2003-01-09 13:16 ` Axel Belinfante
3 siblings, 1 reply; 32+ messages in thread
From: Andrew @ 2003-01-08 22:52 UTC (permalink / raw)
To: 9fans
Maybe this is in the doc's somewhere, but just do i know ahead of time,
does fossil have support for worm devices, ie HP optical jukeboxes and
such? thanks
Andrew
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] 4th edition file server available
2003-01-08 6:45 Russ Cox
` (2 preceding siblings ...)
2003-01-08 22:52 ` Andrew
@ 2003-01-09 13:16 ` Axel Belinfante
3 siblings, 0 replies; 32+ messages in thread
From: Axel Belinfante @ 2003-01-09 13:16 UTC (permalink / raw)
To: 9fans
/sys/doc/fossil.pdf mentions an ``experimental file stack device'' devfs(3).
I'm just curious; is that man page available?
(could not find on plan9 web nor on sources)
Axel.
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2003-02-14 16:04 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-08 8:13 [9fans] 4th edition file server available okamoto
2003-01-08 16:56 ` Russ Cox
-- strict thread matches above, loose matches on Subject: below --
2003-02-10 21:06 Andrey S. Kukhar
2003-01-14 19:13 Russ Cox
2003-01-14 18:23 Skip Tavakkolian
2003-01-14 6:06 okamoto
2003-01-14 13:55 ` David Presotto
2003-02-14 16:04 ` Andrey S. Kukhar
2003-01-13 10:01 Richard Miller
2003-01-13 17:13 ` Russ Cox
2003-01-14 15:20 ` andrey mirtchovski
2003-01-14 18:55 ` Scott Schwartz
2003-01-14 19:11 ` andrey mirtchovski
2003-01-14 19:18 ` andrey mirtchovski
2003-01-14 19:28 ` Russ Cox
2003-01-15 9:34 ` Douglas A. Gwyn
2003-01-15 14:22 ` Russ Cox
2003-01-13 17:19 ` rob pike, esq.
2003-01-12 2:36 Joel Salomon
2003-01-12 3:10 ` jmk
2003-01-09 13:44 rog
2003-01-09 14:39 ` Russ Cox
2003-01-08 7:18 Skip Tavakkolian
2003-01-08 6:45 Russ Cox
2003-01-08 11:09 ` Axel Belinfante
2003-01-08 15:57 ` Fco.J.Ballesteros
2003-01-08 15:56 ` andrey mirtchovski
2003-01-08 16:53 ` Russ Cox
2003-01-08 22:52 ` Andrew
2003-01-08 22:54 ` Russ Cox
2003-01-09 8:24 ` Fco.J.Ballesteros
2003-01-09 13:16 ` Axel Belinfante
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).