-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Mahoney wrote:
> Andrew Morton wrote:
>
>>>Jeff Mahoney <[EMAIL PROTECTED]> wrote:
>>>
>>>
In my experience, the loop is actually outside of
__find_get_block_slow(), in __getblk_slow(). I've been using xmon to
interrupt the kernel,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Mahoney wrote:
> Andrew Morton wrote:
>
>>>Jeff Mahoney <[EMAIL PROTECTED]> wrote:
>>>
>>>
In my experience, the loop is actually outside of
__find_get_block_slow(), in __getblk_slow(). I've been using xmon to
interrupt the kernel,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Mahoney wrote:
Andrew Morton wrote:
Jeff Mahoney [EMAIL PROTECTED] wrote:
In my experience, the loop is actually outside of
__find_get_block_slow(), in __getblk_slow(). I've been using xmon to
interrupt the kernel, and the results vary but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Mahoney wrote:
Andrew Morton wrote:
Jeff Mahoney [EMAIL PROTECTED] wrote:
In my experience, the loop is actually outside of
__find_get_block_slow(), in __getblk_slow(). I've been using xmon to
interrupt the kernel, and the results vary but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morton wrote:
> Jeff Mahoney <[EMAIL PROTECTED]> wrote:
>
>>In my experience, the loop is actually outside of
>>__find_get_block_slow(), in __getblk_slow(). I've been using xmon to
>>interrupt the kernel, and the results vary but are all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morton wrote:
Jeff Mahoney [EMAIL PROTECTED] wrote:
In my experience, the loop is actually outside of
__find_get_block_slow(), in __getblk_slow(). I've been using xmon to
interrupt the kernel, and the results vary but are all rooted in the
I don't know. Can you describe how your driver implements the remapping?
I have tested with ext2. I get double faults when trying to sync.
What are those? (By the look of the error message, I can see they are
not something I want to have :-)
I'm at loss how all of this can happend. All I do is
I don't know. Can you describe how your driver implements the remapping?
I have tested with ext2. I get double faults when trying to sync.
What are those? (By the look of the error message, I can see they are
not something I want to have :-)
I'm at loss how all of this can happend. All I do is
"Thomas S. Iversen" <[EMAIL PROTECTED]> wrote:
>
> > I'd be suspecting that the sector remapping is the cause of the problem.
> > How is it implemented?
>
> Quite simple actually. You're most welcome to see the code, but I have
> just done a test like the one below. Never mind the performance
Something has caused the page at offset 51 (block 102) to have buffer_heads
for blocks 128 and 129 attached to it.
Ok.
I'd be suspecting that the sector remapping is the cause of the problem.
How is it implemented?
Quite simple actually. You're most welcome to see the code, but I have
just done
[EMAIL PROTECTED] (Thomas S. Iversen) wrote:
>
> > OK, so we're looking for the buffer_head for block 101 and the first
> > buffer_head which is attached to the page represents block 100. So the
> > next buffer_head _should_ represent block 101. Please print it out:
>
> Not quite the same, but
> OK, so we're looking for the buffer_head for block 101 and the first
> buffer_head which is attached to the page represents block 100. So the
> next buffer_head _should_ represent block 101. Please print it out:
Not quite the same, but simelar:
Feb 23 14:50:24 localhost kernel:
[EMAIL PROTECTED] (Thomas S. Iversen) wrote:
>
> > > dd if=/dev/zero of=/mnt/testfile count=N, N>6
>
> It turns out N>6 is variable. But large enough and it will hang. Sugests
> some kind of race I am afraid.
>
> > > I get into an endless loop in __find_get_block_slow.
> >
> > The only way
> > dd if=/dev/zero of=/mnt/testfile count=N, N>6
It turns out N>6 is variable. But large enough and it will hang. Sugests
some kind of race I am afraid.
> > I get into an endless loop in __find_get_block_slow.
>
> The only way in which __find_get_block_slow() can loop is if something
>
dd if=/dev/zero of=/mnt/testfile count=N, N6
It turns out N6 is variable. But large enough and it will hang. Sugests
some kind of race I am afraid.
I get into an endless loop in __find_get_block_slow.
The only way in which __find_get_block_slow() can loop is if something
wrecked the
[EMAIL PROTECTED] (Thomas S. Iversen) wrote:
dd if=/dev/zero of=/mnt/testfile count=N, N6
It turns out N6 is variable. But large enough and it will hang. Sugests
some kind of race I am afraid.
I get into an endless loop in __find_get_block_slow.
The only way in which
OK, so we're looking for the buffer_head for block 101 and the first
buffer_head which is attached to the page represents block 100. So the
next buffer_head _should_ represent block 101. Please print it out:
Not quite the same, but simelar:
Feb 23 14:50:24 localhost kernel:
[EMAIL PROTECTED] (Thomas S. Iversen) wrote:
OK, so we're looking for the buffer_head for block 101 and the first
buffer_head which is attached to the page represents block 100. So the
next buffer_head _should_ represent block 101. Please print it out:
Not quite the same, but simelar:
Something has caused the page at offset 51 (block 102) to have buffer_heads
for blocks 128 and 129 attached to it.
Ok.
I'd be suspecting that the sector remapping is the cause of the problem.
How is it implemented?
Quite simple actually. You're most welcome to see the code, but I have
just done
Thomas S. Iversen [EMAIL PROTECTED] wrote:
I'd be suspecting that the sector remapping is the cause of the problem.
How is it implemented?
Quite simple actually. You're most welcome to see the code, but I have
just done a test like the one below. Never mind the performance figures,
Jeff Mahoney <[EMAIL PROTECTED]> wrote:
>
> In my experience, the loop is actually outside of
> __find_get_block_slow(), in __getblk_slow(). I've been using xmon to
> interrupt the kernel, and the results vary but are all rooted in the
> for(;;) loop in __getblk_slow. It appears as though
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morton wrote:
> "Thomas S. Iversen" <[EMAIL PROTECTED]> wrote:
>
>>But if I do
>>
>> dd if=/dev/zero of=/mnt/testfile count=N, N>6
>>
>> I get into an endless loop in __find_get_block_slow.
>
>
> The only way in which
"Thomas S. Iversen" <[EMAIL PROTECTED]> wrote:
>
> But if I do
>
> dd if=/dev/zero of=/mnt/testfile count=N, N>6
>
> I get into an endless loop in __find_get_block_slow.
The only way in which __find_get_block_slow() can loop is if something
wrecked the buffer_head ring at page->private:
Thomas S. Iversen [EMAIL PROTECTED] wrote:
But if I do
dd if=/dev/zero of=/mnt/testfile count=N, N6
I get into an endless loop in __find_get_block_slow.
The only way in which __find_get_block_slow() can loop is if something
wrecked the buffer_head ring at page-private: something caused
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morton wrote:
Thomas S. Iversen [EMAIL PROTECTED] wrote:
But if I do
dd if=/dev/zero of=/mnt/testfile count=N, N6
I get into an endless loop in __find_get_block_slow.
The only way in which __find_get_block_slow() can loop is if
Jeff Mahoney [EMAIL PROTECTED] wrote:
In my experience, the loop is actually outside of
__find_get_block_slow(), in __getblk_slow(). I've been using xmon to
interrupt the kernel, and the results vary but are all rooted in the
for(;;) loop in __getblk_slow. It appears as though grow_buffers is
Hi There
I am trying to develop a device mapper plugin which does transparent
block encryption and sector shuffling in the style freebsd does it (GBDE)
Reads are support and working, but have trouble getting writes to work
properly.
If I do a simple:
echo "test" > /mnt/test (where /mnt is
Hi There
I am trying to develop a device mapper plugin which does transparent
block encryption and sector shuffling in the style freebsd does it (GBDE)
Reads are support and working, but have trouble getting writes to work
properly.
If I do a simple:
echo test /mnt/test (where /mnt is
28 matches
Mail list logo
