[9fans] Possible bug in p9p venti?

[9fans] Possible bug in p9p venti?

[Venkatesh Srinivas]

Hi,

I think I've found a bug in p9p's Venti, if anyone were to take a look
at this code or tell me if I'm on the right track, it'd be pretty
neat.

When trying to start Venti on a FreeBSD 8-BETA2 system and a ZFS
filesystem, we got this error:
2009/0822 23:12:30 venti: conf...
2009/0822 23:12:30 err 4: read arena0 offset 0x60000 count 65536 buf
803f20000 returned 65536: No such file or directory
2009/0822 23:12:30 err 4: can't read arena0: read arena0 offset
0x60000 count 65536 buf 803f20000 returned 65536: No such file or
directory
venti: can't init server: can't initialize venti: arena0: can't read
arena0: read arena0 offset 0x60000 count 65536 buf 803f20000 returned
65536: No such

In venti/srv/part.c:325, opsize is clamped at MaxIo, which is 64KB by
default. Later, on :329, we issue a pread for opsize bytes from our
partition, but check that the read returned some multiple of
blocksize. (Blocksize comes from part->fsblocksize, which is gotten by
fstatfs()'s .f_bsize on unix.) This is a problem when MaxIo <
blocksize ; on ZFS on FreeBSD, f_bsize = 128K.

A workaround is to clamp fsblocksize at MaxIo as well:
--- part.c.orig 2009-08-23 11:07:56.000000000 -0400
+++ part.c  2009-08-23 11:06:46.000000000 -0400
@@ -166,6 +166,9 @@
            part->fsblocksize = sfs.f_bsize;
    }
 #endif
+
+   part->fsblocksize = min(part->fsblocksize, MaxIo);
+
    if(subname && findsubpart(part, subname) < 0){
        werrstr("cannot find subpartition %s", subname);
        freepart(part);

Thanks,
-- vs

Re: [9fans] Possible bug in p9p venti?

[Russ Cox]

> A workaround is to clamp fsblocksize at MaxIo as well:
> +
> +   part->fsblocksize = min(part->fsblocksize, MaxIo);
> +

Sounds good to me.  Submit a patch.

Russ

Re: [9fans] Possible bug in p9p venti?

[J.R. Mauro]

On Sun, Aug 23, 2009 at 11:10 AM, Venkatesh Srinivas<me@acm.jhu.edu> wrote:
> Hi,
>
> I think I've found a bug in p9p's Venti, if anyone were to take a look
> at this code or tell me if I'm on the right track, it'd be pretty
> neat.
>
> When trying to start Venti on a FreeBSD 8-BETA2 system and a ZFS
> filesystem, we got this error:
> 2009/0822 23:12:30 venti: conf...
> 2009/0822 23:12:30 err 4: read arena0 offset 0x60000 count 65536 buf
> 803f20000 returned 65536: No such file or directory
> 2009/0822 23:12:30 err 4: can't read arena0: read arena0 offset
> 0x60000 count 65536 buf 803f20000 returned 65536: No such file or
> directory
> venti: can't init server: can't initialize venti: arena0: can't read
> arena0: read arena0 offset 0x60000 count 65536 buf 803f20000 returned
> 65536: No such
>
> In venti/srv/part.c:325, opsize is clamped at MaxIo, which is 64KB by
> default. Later, on :329, we issue a pread for opsize bytes from our
> partition, but check that the read returned some multiple of
> blocksize. (Blocksize comes from part->fsblocksize, which is gotten by
> fstatfs()'s .f_bsize on unix.) This is a problem when MaxIo <
> blocksize ; on ZFS on FreeBSD, f_bsize = 128K.
>
> A workaround is to clamp fsblocksize at MaxIo as well:
> --- part.c.orig 2009-08-23 11:07:56.000000000 -0400
> +++ part.c  2009-08-23 11:06:46.000000000 -0400
> @@ -166,6 +166,9 @@
>            part->fsblocksize = sfs.f_bsize;
>    }
>  #endif
> +
> +   part->fsblocksize = min(part->fsblocksize, MaxIo);
> +
>    if(subname && findsubpart(part, subname) < 0){
>        werrstr("cannot find subpartition %s", subname);
>        freepart(part);
>
> Thanks,
> -- vs
>
>

Any chance this is related to the issues we discussed on #plan9?

Re: [9fans] Possible bug in p9p venti?

[erik quanstrom]

>
> Any chance this is related to the issues we discussed on #plan9?
>

since not everyone who reads the list does irc, why
don't you fill us in on the issues discussed on #plan9?

- erik

Re: [9fans] Possible bug in p9p venti?

[Venkatesh Srinivas]

On Tue, Aug 25, 2009 at 8:08 PM, erik quanstrom<quanstro@quanstro.net> wrote:
>>
>> Any chance this is related to the issues we discussed on #plan9?
>>

No, I'm pretty sure not. This dealt with a relatively rare case, a
filesystem with an optimal read size larger than a constant in the
Venti source. The constant was 64K, which covered every FS/OS cross I
know of except ZFS on FreeBSD.

>
> since not everyone who reads the list does irc, why
> don't you fill us in on the issues discussed on #plan9?
>

The problem discussed in IRC relates to p9p vac's -a option, which
chains together vac trees to construct something like a dump
filesystem on unix.

The first problem was that a vac -a hadn't be run in a while, and the
newly added tree has some problem with it (either stored incorrectly
or being interpreted incorrectly...), which led to it being impossible
to traverse or base further vacs on.

The person in irc also had a problem where they blew away their Venti
index, rebuilt the index, and had checkindex still report errors. That
problem is pretty exciting too...

-- vs

Re: [9fans] Possible bug in p9p venti?

[J.R. Mauro]

On Tue, Aug 25, 2009 at 8:08 PM, erik quanstrom<quanstro@quanstro.net> wrote:
>>
>> Any chance this is related to the issues we discussed on #plan9?
>>
>
> since not everyone who reads the list does irc, why
> don't you fill us in on the issues discussed on #plan9?
>
> - erik
>
>

Sorry, forgot to crossreference my thread on plan9port-dev:

http://groups.google.com/group/plan9port-dev/browse_thread/thread/54dde001eab50ad9#