bn = addr % h->msize;
msize must be zero.
- erik
Printable View
bn = addr % h->msize;
msize must be zero.
- erik
that was the first thing i checked. in acid, print(cwio:h) showed
seemingly useful non-0 numbers. but apparently i wasn't paying very
close attention: h in cwio is a Cache*, not a Cache, so i needed
print(*cwio:h). yup, msize is zero.
geoff's been providing suggestions and thinks that the recover didn't
actually succeed, so i'm focusing on that case for now. more info as
it presents.
> that was the first thing i checked. in acid, print(cwio:h) showed[color=blue]
> seemingly useful non-0 numbers. but apparently i wasn't paying very
> close attention: h in cwio is a Cache*, not a Cache, so i needed
> print(*cwio:h). yup, msize is zero.
>
> geoff's been providing suggestions and thinks that the recover didn't
> actually succeed, so i'm focusing on that case for now. more info as
> it presents.[/color]
that's what i guessed your problem was. (since msize just had to be zero.)
i would guess that your new fworm is not exactly the same (calculated)
size as your old worm. i think you can fix this by simply dropping the "f"
from your device string. this will inhibit the maintence of the bitmap
at the end of the fake worm.
anyway, what is the compelling reason to move to cwfs? i have been
spending a lot of time with it in the last 6 weeks. i've made some substantial
performance improvements. and i've added aoe.
- erik
On 9/20/07, erik quanstrom <quanstro@quanstro.net> wrote:
// i would guess that your new fworm is not exactly the same (calculated)
// size as your old worm.
the fworm, not the cache? hrm, interesting. it's exactly the same
disks, but i suppose that could be it. i'll take a look at that and
how the bitmap is maintained. i'd expect problems there to show up in
the explicit recover phase (which cwfs's prints say has completed),
but it's worth a check. dropping the "f" is non-destructive in the
face of recover?
i've been looking at auth issues for some of the evening, since it's
complaining about things related to attach. maybe that's a red
herring. i'll take a look at the bitmap tomorrow.
// anyway, what is the compelling reason to move to cwfs?
it's prompted by something in my fs hardware going funny. i suspect
it's just the terminator i have to use on the somewhat odd setup in
that box, but it led to the whole "gee, i'd really like fewer PCs to
maintain" line of thought. the kenfs is also quite old now, and the
size reflects that; i'm considering just moving everything on it over
to venti and putting the box in storage. not to mention a desire to
reduce my power consumption and noise production.
i still think the stand-alone fs has its place, but i don't think my
garage is it.
> the fworm, not the cache? hrm, interesting. it's exactly the same[color=blue]
> disks, but i suppose that could be it. i'll take a look at that and
> how the bitmap is maintained. i'd expect problems there to show up in
> the explicit recover phase (which cwfs's prints say has completed),
> but it's worth a check. dropping the "f" is non-destructive in the
> face of recover?[/color]
yes. recover doesn't touch the w part of the device. it just checks the
block after the last block in each dump to see if it's a sb. if it is it
loops. if it is not, then you're at the end and the cache is cleared.
[color=blue]
> maintain" line of thought. the kenfs is also quite old now, and the
> size reflects that; i'm considering just moving everything on it over
> to venti and putting the box in storage. not to mention a desire to
> reduce my power consumption and noise production.[/color]
kenfs does run on new hardware. i'm currently running it on an
intel 5000-series processor and a brand new mb at coraid. it also
does great with my valinux pIII at home.
[color=blue]
> i still think the stand-alone fs has its place, but i don't think my
> garage is it.[/color]
electricity: $5/month.
noise: too much.
not doing maintence to the fs: priceless. ☺
- erik
perfect. removing the f from the config did the trick exactly. i've
got my fs back. i'd still like to understand more why the bitmap is
wrong on the same disks, but that's for another day now. very much
thanks.
i agree having a file server "just run" is worth quite a bit; the
problem is the hardware in mine no longer fits that description, and
i'm temporarily budget constrained.
again, much thanks.
a
> perfect. removing the f from the config did the trick exactly. i've[color=blue]
> got my fs back. i'd still like to understand more why the bitmap is
> wrong on the same disks, but that's for another day now. very much
> thanks.[/color]
cool..
the problem is that the calculation of the device size is subject
to rounding error and if it's one sector off, you're bitmap won't
be were its supposed to be.
[color=blue]
> i agree having a file server "just run" is worth quite a bit; the
> problem is the hardware in mine no longer fits that description, and
> i'm temporarily budget constrained.[/color]
you can get a valinux box on ebay for $100.
- erik