[9fans] p9p venti sync?

[9fans] p9p venti sync?

[David Leimbach]

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

I'm trying to figure out how to correctly sync a plan9port venti instance so
I can start it back up again and have it actually function :-).

using venti/sync doesn't appear to get the job done...

Dave

[-- Attachment #2: Type: text/html, Size: 266 bytes --]

Re: [9fans] p9p venti sync?

[Bakul Shah]

On Tue, 16 Nov 2010 14:43:20 PST David Leimbach <leimy2k@gmail.com>  wrote:
> --0016e6464d1a9112a304953348f5
> Content-Type: text/plain; charset=ISO-8859-1
>
> I'm trying to figure out how to correctly sync a plan9port venti instance so
> I can start it back up again and have it actually function :-).

>
> using venti/sync doesn't appear to get the job done...

hget http://localhost:9091/flushicache
hget http://localhost:9091/flushdcache

or wherever is your venti has its http port

Re: [9fans] p9p venti sync?

[Russ Cox]

On Tue, Nov 16, 2010 at 5:43 PM, David Leimbach <leimy2k@gmail.com> wrote:
> I'm trying to figure out how to correctly sync a plan9port venti instance so
> I can start it back up again and have it actually function :-).
> using venti/sync doesn't appear to get the job done...

It should.  Not using venti/sync should work too since
vac etc all sync before hanging up.  The flushicache/flushdcache
trick will make restarting a little faster, but it should not
be necessary for correctness and shouldn't even be
that much faster.

Russ

Re: [9fans] p9p venti sync?

[David Leimbach]

On Tuesday, November 16, 2010, Russ Cox <rsc@swtch.com> wrote:
> On Tue, Nov 16, 2010 at 5:43 PM, David Leimbach <leimy2k@gmail.com> wrote:
>> I'm trying to figure out how to correctly sync a plan9port venti instance so
>> I can start it back up again and have it actually function :-).
>> using venti/sync doesn't appear to get the job done...
>
> It should.  Not using venti/sync should work too since
> vac etc all sync before hanging up.  The flushicache/flushdcache
> trick will make restarting a little faster, but it should not
> be necessary for correctness and shouldn't even be
> that much faster.

I did a kill TERM... should the signal handler have cleaned up or was
I supposed to send HUP?


>
> Russ
>
>

Re: [9fans] p9p venti sync?

[Russ Cox]

On Tue, Nov 16, 2010 at 10:19 PM, David Leimbach <leimy2k@gmail.com> wrote:
> On Tuesday, November 16, 2010, Russ Cox <rsc@swtch.com> wrote:
>> On Tue, Nov 16, 2010 at 5:43 PM, David Leimbach <leimy2k@gmail.com> wrote:
>>> I'm trying to figure out how to correctly sync a plan9port venti instance so
>>> I can start it back up again and have it actually function :-).
>>> using venti/sync doesn't appear to get the job done...
>>
>> It should.  Not using venti/sync should work too since
>> vac etc all sync before hanging up.  The flushicache/flushdcache
>> trick will make restarting a little faster, but it should not
>> be necessary for correctness and shouldn't even be
>> that much faster.
>
> I did a kill TERM... should the signal handler have cleaned up or was
> I supposed to send HUP?

There's no cleanup.  The data's on disk after a sync RPC,
which is what venti/sync does and also what vac does when
it is done.  Venti's writes are ordered so that the on-disk state
is always recoverable.  Because of that, there's no explicit
shutdown: you just kill the server however you like.

Russ

Re: [9fans] p9p venti sync?

[David Leimbach]

Could sparse files be an issue?  Bloom always shows up wrong when I restart.

On Tuesday, November 16, 2010, David Leimbach <leimy2k@gmail.com> wrote:
> On Tuesday, November 16, 2010, Russ Cox <rsc@swtch.com> wrote:
>> On Tue, Nov 16, 2010 at 5:43 PM, David Leimbach <leimy2k@gmail.com> wrote:
>>> I'm trying to figure out how to correctly sync a plan9port venti instance so
>>> I can start it back up again and have it actually function :-).
>>> using venti/sync doesn't appear to get the job done...
>>
>> It should.  Not using venti/sync should work too since
>> vac etc all sync before hanging up.  The flushicache/flushdcache
>> trick will make restarting a little faster, but it should not
>> be necessary for correctness and shouldn't even be
>> that much faster.
>
> I did a kill TERM... should the signal handler have cleaned up or was
> I supposed to send HUP?
>
>
>>
>> Russ
>>
>>
>

Re: [9fans] p9p venti sync?

[David Leimbach]

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

On Tue, Nov 16, 2010 at 8:09 PM, David Leimbach <leimy2k@gmail.com> wrote:

> Could sparse files be an issue?  Bloom always shows up wrong when I
> restart.
>

Nope... Didn't make a difference it seems.

I recreated my venti setup, and it starts ok.  I do a vac and an unvac, then
kill it and restart and get the following:

% venti/venti
2010/1116 20:44:14 venti: conf...2010/1116 20:44:14 err 4: read
/Users/dave/venti/disks/bloom offset 0x0 count 65536 buf 3800000 returned
65536: No such file or directory
venti/venti: can't load bloom filter: read /Users/dave/venti/disks/bloom
offset 0x0 count 65536 buf 3800000 returned 65536: No such file or
directory

bloom is definitely there though... Not sure what the no such file or
directory is referring to just yet.
-rw-r--r--  1 dave  wheel   33554432 Nov 16 20:42 bloom

I'll try without the bloom filter.


> On Tuesday, November 16, 2010, David Leimbach <leimy2k@gmail.com> wrote:
> > On Tuesday, November 16, 2010, Russ Cox <rsc@swtch.com> wrote:
> >> On Tue, Nov 16, 2010 at 5:43 PM, David Leimbach <leimy2k@gmail.com>
> wrote:
> >>> I'm trying to figure out how to correctly sync a plan9port venti
> instance so
> >>> I can start it back up again and have it actually function :-).
> >>> using venti/sync doesn't appear to get the job done...
> >>
> >> It should.  Not using venti/sync should work too since
> >> vac etc all sync before hanging up.  The flushicache/flushdcache
> >> trick will make restarting a little faster, but it should not
> >> be necessary for correctness and shouldn't even be
> >> that much faster.
> >
> > I did a kill TERM... should the signal handler have cleaned up or was
> > I supposed to send HUP?
> >
> >
> >>
> >> Russ
> >>
> >>
> >
>

[-- Attachment #2: Type: text/html, Size: 2637 bytes --]

Re: [9fans] p9p venti sync?

[David Leimbach]

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

>
>
> I'll try without the bloom filter.
>
> Now it's working... I probably don't need this enhancement anyway, but at
least it appears to be working now.  Unvac of a previously generated score
is working fine.

Dave


>
>> On Tuesday, November 16, 2010, David Leimbach <leimy2k@gmail.com> wrote:
>> > On Tuesday, November 16, 2010, Russ Cox <rsc@swtch.com> wrote:
>> >> On Tue, Nov 16, 2010 at 5:43 PM, David Leimbach <leimy2k@gmail.com>
>> wrote:
>> >>> I'm trying to figure out how to correctly sync a plan9port venti
>> instance so
>> >>> I can start it back up again and have it actually function :-).
>> >>> using venti/sync doesn't appear to get the job done...
>> >>
>> >> It should.  Not using venti/sync should work too since
>> >> vac etc all sync before hanging up.  The flushicache/flushdcache
>> >> trick will make restarting a little faster, but it should not
>> >> be necessary for correctness and shouldn't even be
>> >> that much faster.
>> >
>> > I did a kill TERM... should the signal handler have cleaned up or was
>> > I supposed to send HUP?
>> >
>> >
>> >>
>> >> Russ
>> >>
>> >>
>> >
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2125 bytes --]

Re: [9fans] p9p venti sync?

[Russ Cox]

> % venti/venti
> 2010/1116 20:44:14 venti: conf...2010/1116 20:44:14 err 4: read
> /Users/dave/venti/disks/bloom offset 0x0 count 65536 buf 3800000 returned
> 65536: No such file or directory

A read of 65536 returning 65536 should not be an error.
If you want to dig in, this is $PLAN9/src/cmd/venti/srv/part.c:/^prwb.
There have been problems with short reads before.

Russ

Re: [9fans] p9p venti sync?

[David Leimbach]

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

On Wed, Nov 17, 2010 at 6:36 AM, Russ Cox <rsc@swtch.com> wrote:

> > % venti/venti
> > 2010/1116 20:44:14 venti: conf...2010/1116 20:44:14 err 4: read
> > /Users/dave/venti/disks/bloom offset 0x0 count 65536 buf 3800000 returned
> > 65536: No such file or directory
>
> A read of 65536 returning 65536 should not be an error.
> If you want to dig in, this is $PLAN9/src/cmd/venti/srv/part.c:/^prwb.
> There have been problems with short reads before.
>
> Russ
>
> I will look at this later tonight.  It only happens when using a bloom file
apparently so far.

Dave

[-- Attachment #2: Type: text/html, Size: 922 bytes --]