| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
On Wed, Apr 09, 2003 at 08:01:32AM -0700, Cahill, Ben M wrote:
[snip] [snip] [snip]
> I've been focused on getting rid of pool, rather than repairing it (as
> tempting as it was to do so), otherwise I would have tracked down what is
> causing the bogus "poola" entries in /proc/partitions.
Yes, sure. But I need some code that at least works so I can set
up a test cluster.
> I don't see anything that tells dd how many sectors to read . . . is it
> possible that it just keeps on reading past the end of the pool capacity (I
> haven't used dd much)? If so, the error messages make (almost) perfect
> sense.
I don't know exactly, but I assume the pool driver lies about the
pool size to make the kernel try accessing invalid block numbers.
Otherwise I don't see how it could grow automatically. The read
ahead mechanism in the kernel may play a role too. And this is
really a stupid thing to do because *every* time a request exceeds
the current pool size, it scans *all* partitions for pool labels.
> > B. Then I run dd again:
> >
> > $ dd if=/dev/pool/poola_cidev of=/dev/null
> > dd: reading `/dev/pool/poola_cidev': Input/output error
> > 0+0 records in
> > 0+0 records out
> >
> > Note that this time it did not read a single sector. It looks
> > completely different in /var/log/messages:
> >
> > kernel:
> > kernel: block requested past end of subpool at line 1448!
>
> Does dd try to pick up where it left off (i.e. after the end of the pool
> capacity)??
No. I debugged a while and noticed that the structure describing
the device layout of the pool devices gets overwritten. On the
second run, I see random values in devp->d_start and devp->d_nblks
in this piece of code (pool_blkmap(), src/pool/common.c):
for (i = 0; i < devnum; i++) {
devp = &(sp->sp_devlist[i]);
if (((psector - sp->sp_start) >= devp->d_start) &&
((psector - sp->sp_start) <
(devp->d_start + devp->d_nblks)))
break;
}
I'm trying to get the pool module working in uml so that I can
attach a debugger.
> > C. Unload the pools:
> >
> > $ passemble -r all
> > Segmentation fault
> >
> > This makes the kernel oops:
>
> Again, try using "pool0" and "pool0_cidev" in your pool config file, and see
> if the problem persists.
Argh, I'd never have thought of this. The problem goes away if I
choose a different pool name.
> pool definitely has some rough edges . . . that's one reason we want to get
> rid of it.
Is that documented somewhere? Ideally, ptool shoud reject such
pool names from the start.
Bye
Dominik ^_^ ^_^
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Opengfs-devel mailing list
Opengfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opengfs-devel