[9fans] p9p venti problem

[9fans] p9p venti problem

[Adrian Tritschler]

I've got a p9p venti running on two separate ubuntu linux boxes that
I've been using for months to keep backups of data and for QEMU plan9
guests.  They have both stopped working, I suspect due to a recent
ubuntu kernel update.  I've rebuilt all of p9p but to no avail.

The QEMU guests crash on boot stating "error reading block 43a72...3
or wrong score: read too small 1: asked for 0 need at le...
panic: boot process died: unknown"

Any attempt to write data into either venti on the linux systems fails
with the error:

ajft@xyz:~/tmp$ vac x
create bsize 8192 psize 8160
vac: vacfscreate: vacfileroot: read too small 1: asked for 0 need at least 389

reading any existing *.vac file also fails:

ajft@xyz:~/venti/2009/04/24$ unvac -t xyz_bin-2009-04-24.vac
unvac: vacfsopen: read too small 1: asked for 0 need at least 300

Any ideas?
--
Adrian

Re: [9fans] p9p venti problem

[J.R. Mauro]

I can't help with this in particular, but QEMU does some really
low-level hackery to the point where it wouldn't compile with GCC 4,
so it's possible something like that is going on here.

On Thu, Jun 11, 2009 at 8:06 PM, Adrian Tritschler<ajft@ajft.org> wrote:
> I've got a p9p venti running on two separate ubuntu linux boxes that
> I've been using for months to keep backups of data and for QEMU plan9
> guests.  They have both stopped working, I suspect due to a recent
> ubuntu kernel update.  I've rebuilt all of p9p but to no avail.
>
> The QEMU guests crash on boot stating "error reading block 43a72...3
> or wrong score: read too small 1: asked for 0 need at le...
> panic: boot process died: unknown"
>
> Any attempt to write data into either venti on the linux systems fails
> with the error:
>
> ajft@xyz:~/tmp$ vac x
> create bsize 8192 psize 8160
> vac: vacfscreate: vacfileroot: read too small 1: asked for 0 need at least 389
>
> reading any existing *.vac file also fails:
>
> ajft@xyz:~/venti/2009/04/24$ unvac -t xyz_bin-2009-04-24.vac
> unvac: vacfsopen: read too small 1: asked for 0 need at least 300
>
> Any ideas?
> --
> Adrian
>
>

Re: [9fans] p9p venti problem

[Venkatesh Srinivas]

On Thu, Jun 11, 2009 at 11:00 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
> I can't help with this in particular, but QEMU does some really
> low-level hackery to the point where it wouldn't compile with GCC 4,
> so it's possible something like that is going on here.

Thankfully, this is no longer true. QEMU 0.10 relies on completely
different low-level hackery...

-- vs

Re: [9fans] p9p venti problem

[Venkatesh Srinivas]

Adrian, how recent is you p9p checkout?

Also, could you set 'verbose' to 1 in plan9port/src/cmd/venti/copy.c,
rebuild, and try to copy this score to another (temporary) venti? This
should show you what scores are referenced by your root score. I've
had problems with Venti on p9p trying to read the zero score (score
with hash=0x0) in the past... wondering if that's the problem now.

-- vs

Re: [9fans] p9p venti problem

[Adrian Tritschler]

2009/6/12 Venkatesh Srinivas <me@acm.jhu.edu>:
> Adrian, how recent is you p9p checkout?

A daily update from the mercurial repository.  Perhaps I should be a
little less bleeding edge...

> Also, could you set 'verbose' to 1 in plan9port/src/cmd/venti/copy.c,
> rebuild, and try to copy this score to another (temporary) venti? This
> should show you what scores are referenced by your root score. I've
> had problems with Venti on p9p trying to read the zero score (score
> with hash=0x0) in the past... wondering if that's the problem now.

I've done that but never get the "Skip" message, but it does seem to
be complaining about the zero block.

% unvac -t vac:8ab4746b0fb06da481158624afb7509cefc35e07
unvac: vacfsopen: read too small 1: asked for 0 need at least 300

% venti/copy 'tcp!localhost!17034' 'tcp!localhost!17034'
vac:8ab4746b0fb06da481158624afb7509cefc35e07
venti/copy: reading block 0000000000000000000000000000000000000000
(type 16): read asked for 0000000000000000000000000000000000000000 got
da39a3ee5e6b4b0d3255bfef95601890afd80709

> -- vs

--
Adrian

Re: [9fans] p9p venti problem

[Venkatesh Srinivas]

> % unvac -t vac:8ab4746b0fb06da481158624afb7509cefc35e07
> unvac: vacfsopen: read too small 1: asked for 0 need at least 300
>
> % venti/copy 'tcp!localhost!17034' 'tcp!localhost!17034'
> vac:8ab4746b0fb06da481158624afb7509cefc35e07
> venti/copy: reading block 0000000000000000000000000000000000000000
> (type 16): read asked for 0000000000000000000000000000000000000000 got
> da39a3ee5e6b4b0d3255bfef95601890afd80709

I think you've run into the same bug I did in February:
http://9fans.net/archive/2009/02/198
Or at least a close cousin.

da39a3ee5e6b4b0d3255bfef95601890afd80709 is the sha1sum of the empty
string; somehow someone is looking for the all-zero score instead...

-- vs

Re: [9fans] p9p venti problem

[Venkatesh Srinivas]

Inside plan9port/src/cmd/venti/srv/lump.c, in readlump(), could you
check that the score being read is a sane one? (not the zero-score)
Just printing it out for now would be enough.

Thanks,
-- vs

Re: [9fans] p9p venti problem

[J. R. Mauro]

On Jun 11, 2009, at 23:34, Venkatesh Srinivas <me@acm.jhu.edu> wrote:

> On Thu, Jun 11, 2009 at 11:00 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
>> I can't help with this in particular, but QEMU does some really
>> low-level hackery to the point where it wouldn't compile with GCC 4,
>> so it's possible something like that is going on here.
>
> Thankfully, this is no longer true. QEMU 0.10 relies on completely
> different low-level hackery...
>
> -- vs
>

Oh neato! I've been wanting to run it on my system, but didn't want to
wait a month for GCC 3 to compile

Re: [9fans] p9p venti problem

[Mathieu]

On Jun 12, 10:14 am, m...@acm.jhu.edu (Venkatesh Srinivas) wrote:
> > % unvac -t vac:8ab4746b0fb06da481158624afb7509cefc35e07
> > unvac: vacfsopen: read too small 1: asked for 0 need at least 300
>
> > %venti/copy 'tcp!localhost!17034' 'tcp!localhost!17034'
> > vac:8ab4746b0fb06da481158624afb7509cefc35e07
> >venti/copy: reading block 0000000000000000000000000000000000000000
> > (type 16): read asked for 0000000000000000000000000000000000000000 got
> > da39a3ee5e6b4b0d3255bfef95601890afd80709
>
> I think you've run into the same bug I did in February:http://9fans.net/archive/2009/02/198
> Or at least a close cousin.
>
> da39a3ee5e6b4b0d3255bfef95601890afd80709 is the sha1sum of the empty
> string; somehow someone is looking for the all-zero score instead...
>
> -- vs

Hello,

It seems like I've just hit the same issue:
lejatorn@oenone:~/tmp$ unvac -h localhost ../work/venti/20090605.vac
unvac: vacfsopen: read too small 1: asked for 0 need at least 300

At first I thought the index was corrupted because I had to hard
reboot that
machine while venti was running.
checkindex -f detects some errors but does not seem to be fixing them:

 lejatorn@oenone:~/work/venti$ /usr/local/plan9/bin/venti/checkindex -
f venti.conf /home/lejatorn/tmpisect
checkindex: building entry list
constructing entry list
	arena arenas00: 2554 entries
[arenas01] sorting 2554 entries
checkindex: checking 2554 entries at 16777216
# diff actual correct
isect block 0x184000
> 04665caf88387b2a9f925ca5d958d2cfd5748d3c               10067426   0   724   1
isect block 0x1ae000
> 0558ba6343c0256c2daa851bb81dbd7fb2a2b9e7               10069700   0  2063   2
isect block 0x4b6000
> 16f19e6591bfe468f489c88fe0c6cf607c107c5c               10068499   8  1840   3
isect block 0x612000
> 1ecbb5af8ee870174e099e5c9bc84c944beec01f               10064704   0   744   1
isect block 0x65c000
> 207f10e6f8a66dab242b1f0d8226b0a18436ffcd               10067090   8   440   1
isect block 0xa7e000
> 386a02c7fe558550107853d9788ad72f2f9053f2               10068283   8    80   1
isect block 0xada000
> 3a7dc491bf6078e9d16c3fd6bad14d638a709c85               10070360   8   120   1
isect block 0xfae000
> 5682a0fb0a24fbf36bfb4308865ab45aa6bf3b15               10067991   0   835   1
isect block 0x127a000
> 66b430198ea34f4e734bde565804bd0be3f23dfd               10064925   8   240   1
isect block 0x147c000
> 7254aa4af20a94ea73ee46b9b7a419129131c0ad               10070255   8    80   1
isect block 0x1584000
> 784875610550ac6a10111c6d3266056f8e1c9171               10066161   0   740   1
isect block 0x160e000
> 7b6d56b5bf715fe3972bb0f614621f0cc90225c3               10067646   8   440   1
isect block 0x1676000
> 7dc3a7c680e0e8c1c61ce446cd645f57a619b409               10065348   0  1587   1
isect block 0x1774000
> 8384ca87c033a4c64e14894202d3570491f00f8d               10066882   0   678   1
isect block 0x186e000
> 892c639a60cdad7409482362d340afd5b7c7cd5e               10066385   0   813   1
isect block 0x1b36000
> 994fba051c5c1895417d15e993e1f4e4905df20d               10065818   0   477   1
isect block 0x1c36000
> 9f1b4cc34e917fc7a81b7bc35960e2e7467a8c19               10065959   0   673   1
isect block 0x1d0e000
> a3fde373beeb7d74007788fa2654436a7f260e0b               10068387   0   403   1
isect block 0x1fd2000
> b402d8db94260e233c6c0b7e4282dd0e77df9c87               10066647   0   811   1
isect block 0x2308000
> c6a3e8b8b8b181dfc25ce22df91cadb2a3b87f4b               10065133   0   706   1
isect block 0x2a82000
> f1ee1f851ab24bb5a2e7bb5ae7aa3a78c904e221               10070491  16   300   1
checkindex: 0 spurious entries, 21 missing, 0 wrong
bloom filter: correct
/usr/local/plan9/bin/venti/checkindex: errors found

Is there any way I can recover any data at all?
Would rebuilding unvac from an older pull of plan9port help ?

Cheers,
Mathieu