Now I start the server with -D flag and try ''echo hello >>foo" on
Linux. The server side on Plan 9 say:
<-5- Twalk tag 1 fid 408 newfid 437 nwname 1 0:foo
-5-> Rwalk tag 1 nwqid 1 0:( 0 )
<-5- Tstat tag 1 fid 437
-5-> Rstat tag 1 stat 'foo' 'bootes' 'bootes' 'unkn
Hello,
Summary of the previous epidodes: My Plan9 installation was still the
initial one as far as partitionning is concerned. Since I had not
grasped the venti purpose, "other" was empty, everything going into
the venti archived. And I was doing a number of install/de-install
of kerTeX for tests
> So the compiled result is not worth archiving.
it has been more than once that in tracking down a problem, i've
found that the "known working" executable worked but the source
from that point in history didn't. and vice versa. having the executables
and libraries archived was very valuable.
o
On Thu, Jan 05, 2012 at 07:59:00AM -0500, erik quanstrom wrote:
> > So the compiled result is not worth archiving.
>
> it has been more than once that in tracking down a problem, i've
> found that the "known working" executable worked but the source
> from that point in history didn't. and vice v
On Thu, Jan 05, 2012 at 02:20:34PM +0100, tlaro...@polynum.com wrote:
> And finally, didn't the increase in size of the disks, with
>no decrease
no increase, of course. If probability of a failure for a sector is P,
increasing the number of sectors increases the probability of disk
f
> Perhaps, but it seems to me like digging ore, extracting the small
> percentage of valuable; forging a ring; and throwing it in the ore, and
> storing the whole...
generally it's apparent which files are worth investigating, and between
history (list of changes by date) and a binary search, it s
On Thu, Jan 05, 2012 at 08:27:50AM -0500, erik quanstrom wrote:
>
> > Secondly, I still use optical definitive storage from time to time
> > (disks go in a vault)... with KerGIS and others, and kerTeX, this still
> > fit 3 times on a CDROM. So...
>
> if you are using venti, there is no reason to
I am not sure to understand your question.
Nothing forces you to dump the full Fossil tree to Venti
every night. You can run snap manually every time you
want, or run it only on a part of the tree.
You can also individually exclude some files from
the snapshots using the DMTMP bit.
If you really
> Because I use CVS (not on Plan9), and I backup my CVS. So, sources with
> history. I do not consider CDROM to be eternal. So there is a small
> number kept, and the older is destroyed when the new one is burnt.
sorry. i thought we were talking about organizing plan 9
storage. never mind
On Thu Jan 5 08:28:57 EST 2012, tlaro...@polynum.com wrote:
> On Thu, Jan 05, 2012 at 02:20:34PM +0100, tlaro...@polynum.com wrote:
> > And finally, didn't the increase in size of the disks, with
> >no decrease
>
>
> no increase, of course. If probability of a failure for a sector i
On Thu, Jan 05, 2012 at 09:14:28AM -0500, erik quanstrom wrote:
> > Because I use CVS (not on Plan9), and I backup my CVS. So, sources with
> > history. I do not consider CDROM to be eternal. So there is a small
> > number kept, and the older is destroyed when the new one is burnt.
>
> sorry. i t
On Thu, Jan 05, 2012 at 02:48:10PM +0100, David du Colombier wrote:
>
> Fossil and Venti are very flexible, you can do almost
> everything you want.
No doubt about that.
But perhaps the other users are smart enough to have understood all this
at installation time, but when I first installed Plan
On Thu, Jan 5, 2012 at 10:15 AM, wrote:
> But perhaps the other users are smart enough to have understood all this
> at installation time, but when I first installed Plan9, that was not for
> the archival features. And I spent my time on Plan9 looking for the
> distributed system, the namespace a
On Thu, Jan 05, 2012 at 10:44:18AM -0500, Russ Cox wrote:
>
> The default is that you have so little data in comparison to a
> modern disk that there is no good reason not to save full
> snapshots. As Erik and others have pointed out, if you do
> find reason to exclude certain trees from the snap
The third edition was published in june 2000. It predates
both Venti (april 2002) and Fossil (january 2003).
This documentation was about installing Plan 9 on a
standalone terminal running kfs, not a file server.
--
David du Colombier
I doubt anyone would object if you want to change the text and submit
to the website owners.
ron
Russ Cox writes:
> run venti/sync.
Ah. Cool. Gotta love those undocumented commands. :) While probing
the distal edges of Venti's documented functionality, I also came across
the following, which have similar (but not identical) effect:
hget http://$vthost:$vtwebport/flushicache
hget http://
"Steve Simon" writes:
> Even fossil can be grown though you will need a new bigger
> partition or grow the existing one using fs(3), this can then
> be refreshed from a venti snapshot.
Quid pro quo: IIRC, if you do this (using flfmt), you will retain venti
archives of the fossil filesystem, but
On Thu, 05 Jan 2012 17:39:07 +0100 tlaro...@polynum.com wrote:
> On Thu, Jan 05, 2012 at 10:44:18AM -0500, Russ Cox wrote:
> >
> > The default is that you have so little data in comparison to a
> > modern disk that there is no good reason not to save full
> > snapshots. As Erik and others have p
erik quanstrom wrote:
> for me, the most important questions are
> - how do i set up a raid/hot spares, and
> - can i do this without rebooting.
Of course, and right now I'm doing exactly that using a different
operating system. Can I do that on Plan 9? I don't know, I'm trying
to find out withou
> On Thu, Jan 5, 2012 at 10:15 AM, wrote:
>> But perhaps the other users are smart enough to have understood all this
>> at installation time, but when I first installed Plan9, that was not for
>> the archival features. And I spent my time on Plan9 looking for the
>> distributed system, the names
> if you read 1TB, you have 8% chance of a silent bad read
> sector. More important to worry about that in today's world
> than optimizing disk space use.
do you have a citation for this? i know if you work out the
numbers from the BER, this is about what you get, but in
practice i do not see th
On Thu, Jan 05, 2012 at 09:36:13AM -0800, ron minnich wrote:
> I doubt anyone would object if you want to change the text and submit
> to the website owners.
That was my intention, but before, I wanted to submit to the list some
stuff, in order to not publish nonsense. [But probably some people eq
On Thu, Jan 05, 2012 at 10:07:08AM -0800, John Floren wrote:
>
> For reference, I set up our current Plan 9 system about half a year
> ago. We have 3.8 TB of Venti storage total. We have used 2.8 GB of
> that, with basically no precautions taken to set anything +t; in
> general, if it's around a
venti/sync calls vtsync which is documented in venti-client(2).
Hopefully, you don't have to flush the dcache or icache before
shutting down Venti. Especially since flushing the icache will
likely take a very long time.
--
David du Colombier
On Thu, 05 Jan 2012 13:01:52 EST erik quanstrom wrote:
> > if you read 1TB, you have 8% chance of a silent bad read
> > sector. More important to worry about that in today's world
> > than optimizing disk space use.
>
> do you have a citation for this? i know if you work out the
> numbers from
On Thu, 05 Jan 2012 10:07:08 PST "John Floren" wrote:
>
> For reference, I set up our current Plan 9 system about half a year
> ago. We have 3.8 TB of Venti storage total. We have used 2.8 GB of
> that, with basically no precautions taken to set anything +t; in
> general, if it's around at 4 a
On Thu Jan 5 13:26:16 EST 2012, ba...@bitblocks.com wrote:
> On Thu, 05 Jan 2012 13:01:52 EST erik quanstrom
> wrote:
> > > if you read 1TB, you have 8% chance of a silent bad read
> > > sector. More important to worry about that in today's world
> > > than optimizing disk space use.
> >
> >
> On Thu, 05 Jan 2012 10:07:08 PST "John Floren" wrote:
>>
>> For reference, I set up our current Plan 9 system about half a year
>> ago. We have 3.8 TB of Venti storage total. We have used 2.8 GB of
>> that, with basically no precautions taken to set anything +t; in
>> general, if it's around
> You'd save a bunch of energy if you only powered up venti
> disks once @ 4AM for a few minutes (and on demand when you
> look at /n/dump). Though venti might have fits! And the disks
> might too! So may be this calls for a two level venti? First
> to an SSD RAID and a much less frequent venti/co
On Thu, Jan 5, 2012 at 12:35 PM, wrote:
>> run venti/sync.
>
> Ah. Cool. Gotta love those undocumented commands. :) While probing
> the distal edges of Venti's documented functionality, I also came across
> the following, which have similar (but not identical) effect:
>
> hget http://$vthost:$
>> venti doesn't have a "scrub" command, does it? zfs scrub was
>> instrumental in warning me that I needed new disks.
>
> they're using coraid storage. all this is taken care of for them
> by the SR appliance.
Out of curiosity, how? ZFS blocks are checksummed. ZFS scrub reads
not physical block
On Thu Jan 5 14:13:55 EST 2012, ara...@mgk.ro wrote:
> >> venti doesn't have a "scrub" command, does it? zfs scrub was
> >> instrumental in warning me that I needed new disks.
> >
> > they're using coraid storage. all this is taken care of for them
> > by the SR appliance.
>
> Out of curiosity,
but john, the whole your venti would easily fit in even a small server
memory, now and forever ;)
ron
> For reference, I set up our current Plan 9 system about half a year
> ago. We have 3.8 TB of Venti storage total. We have used 2.8 GB of
> that, with basically no precautions taken to set anything +t; in
> general, if it's around at 4 a.m., it's going into Venti. I figure we
> have roughly ano
On Thu, 05 Jan 2012 13:43:49 EST erik quanstrom wrote:
> On Thu Jan 5 13:26:16 EST 2012, ba...@bitblocks.com wrote:
> > On Thu, 05 Jan 2012 13:01:52 EST erik quanstrom wr
> ote:
> > > > if you read 1TB, you have 8% chance of a silent bad read
> > > > sector. More important to worry about that
On Thu, 05 Jan 2012 13:50:48 EST erik quanstrom wrote:
> > You'd save a bunch of energy if you only powered up venti
> > disks once @ 4AM for a few minutes (and on demand when you
> > look at /n/dump). Though venti might have fits! And the disks
> > might too! So may be this calls for a two leve
> > > venti doesn't have a "scrub" command, does it? zfs scrub was
> > > instrumental in warning me that I needed new disks.
> >
> > they're using coraid storage. all this is taken care of for them
> > by the SR appliance.
>
> When are you going to sell these retail?!
>
> The question was for ve
> You'd save a bunch of energy if you only powered up venti
> disks once @ 4AM for a few minutes (and on demand when you
> look at /n/dump).
If fossil is setup to dump to venti then it needs venti to
work at all. Fossil is a write cache, so, just after the dump
at 4am fossil is empty and consists
2012/1/5 Bakul Shah :
> You'd save a bunch of energy if you only powered up venti
> disks once @ 4AM for a few minutes (and on demand when you
> look at /n/dump). Though venti might have fits! And the disks
> might too! So may be this calls for a two level venti? First
> to an SSD RAID and a much
On Thu Jan 5 16:24:58 EST 2012, yari...@gmail.com wrote:
> 2012/1/5 Bakul Shah :
> > You'd save a bunch of energy if you only powered up venti
> > disks once @ 4AM for a few minutes (and on demand when you
> > look at /n/dump). Though venti might have fits! And the disks
> > might too! So may be
erik quanstrom wrote:
> do you have a citation for this? i know if you work out the
> numbers from the BER, this is about what you get, but in
> practice i do not see this 8%. we do pattern writes all the
> time, and i can't recall the last time i saw a "silent" read error.
Yes, the real numbers
42 matches
Mail list logo
