Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
> I have measured the bh refcount before the buffer_uptodate() for a few days.
> I found out that the bh refcount sometimes reached to 0 .
> So, I think following modifications are effective.
>
> diff -Nru 2.4.30-rc3/fs/jbd/commit.c
Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
I have measured the bh refcount before the buffer_uptodate() for a few days.
I found out that the bh refcount sometimes reached to 0 .
So, I think following modifications are effective.
diff -Nru 2.4.30-rc3/fs/jbd/commit.c
Hi,
On Mon, 2005-04-11 at 21:46, Andrew Morton wrote:
> "Stephen C. Tweedie" <[EMAIL PROTECTED]> wrote:
> >
> > Andrew, what was the exact illegal state of the pages you were seeing
> > when fixing that recent leak? It looks like it's nothing more complex
> > than dirty buffers on an anon
"Stephen C. Tweedie" <[EMAIL PROTECTED]> wrote:
>
> Andrew, what was the exact illegal state of the pages you were seeing
> when fixing that recent leak? It looks like it's nothing more complex
> than dirty buffers on an anon page.
Correct.
> I think that simply calling
>
Hi,
On Thu, 2005-04-07 at 16:51, Stephen C. Tweedie wrote:
> I'm currently running with the buffer-trace debug patch, on 2.4, with a
> custom patch to put every buffer jbd ever sees onto a per-superblock
> list, and remove it only when the bh is destroyed in
> put_unused_buffer_head(). At
Hi,
On Thu, 2005-04-07 at 16:51, Stephen C. Tweedie wrote:
I'm currently running with the buffer-trace debug patch, on 2.4, with a
custom patch to put every buffer jbd ever sees onto a per-superblock
list, and remove it only when the bh is destroyed in
put_unused_buffer_head(). At unmount
Stephen C. Tweedie [EMAIL PROTECTED] wrote:
Andrew, what was the exact illegal state of the pages you were seeing
when fixing that recent leak? It looks like it's nothing more complex
than dirty buffers on an anon page.
Correct.
I think that simply calling
try_to_release_page() for
Hi,
On Mon, 2005-04-11 at 21:46, Andrew Morton wrote:
Stephen C. Tweedie [EMAIL PROTECTED] wrote:
Andrew, what was the exact illegal state of the pages you were seeing
when fixing that recent leak? It looks like it's nothing more complex
than dirty buffers on an anon page.
Correct.
Hi,
On Wed, 2005-04-06 at 21:10, Stephen C. Tweedie wrote:
> However, 2.6 is suspected of still having leaks in ext3. To be certain
> that we're not just backporting one of those to 2.4, we need to
> understand who exactly is going to clean up these bh's if they are in
> fact unused once we
Hi,
On Wed, 2005-04-06 at 21:10, Stephen C. Tweedie wrote:
However, 2.6 is suspected of still having leaks in ext3. To be certain
that we're not just backporting one of those to 2.4, we need to
understand who exactly is going to clean up these bh's if they are in
fact unused once we
Hi,
At 23:20 05/04/06, Stephen C. Tweedie wrote:
>Yes. But it is conventional to interpret a short write as being a
>failure. Returning less bytes than were requested in the write
>indicates that the rest failed. It just doesn't give the exact nature
>of the failure (EIO vs ENOSPC etc.) For
Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
> I have measured the bh refcount before the buffer_uptodate() for a few days.
> I found out that the bh refcount sometimes reached to 0 .
> So, I think following modifications are effective.
Thanks --- it certainly looks like this should
Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
> >Certainly it's normal for a short read/write to imply either error or
> >EOF, without the error necessarily needing to be returned explicitly.
> >I'm not convinced that the Singleunix language actually requires that,
> >but it seems
Hi.
At 07:40 05/04/06, Stephen C. Tweedie wrote:
>Sorry, was offline for a week last week; I'll try to look at this more
>closely tomorrow. Checking the buffer_uptodate() without either a
>refcount or a lock certainly looks unsafe at first glance.
>
>There are lots of ways to pin the bh in that
Hi.
At 07:40 05/04/06, Stephen C. Tweedie wrote:
Sorry, was offline for a week last week; I'll try to look at this more
closely tomorrow. Checking the buffer_uptodate() without either a
refcount or a lock certainly looks unsafe at first glance.
There are lots of ways to pin the bh in that
Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
Certainly it's normal for a short read/write to imply either error or
EOF, without the error necessarily needing to be returned explicitly.
I'm not convinced that the Singleunix language actually requires that,
but it seems the most
Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
I have measured the bh refcount before the buffer_uptodate() for a few days.
I found out that the bh refcount sometimes reached to 0 .
So, I think following modifications are effective.
Thanks --- it certainly looks like this should fix
Hi,
At 23:20 05/04/06, Stephen C. Tweedie wrote:
Yes. But it is conventional to interpret a short write as being a
failure. Returning less bytes than were requested in the write
indicates that the rest failed. It just doesn't give the exact nature
of the failure (EIO vs ENOSPC etc.) For
Hi,
On Wed, 2005-03-30 at 12:59, Marcelo Tosatti wrote:
> > I'm not certain that this is right, but it seems possible and would
> > explain the symptoms. Maybe Stephen or Andrew could comments?
>
> Andrew, Stephen?
Sorry, was offline for a week last week; I'll try to look at this more
closely
Hi,
On Wed, 2005-03-30 at 12:59, Marcelo Tosatti wrote:
I'm not certain that this is right, but it seems possible and would
explain the symptoms. Maybe Stephen or Andrew could comments?
Andrew, Stephen?
Sorry, was offline for a week last week; I'll try to look at this more
closely
On Wed, Mar 30, 2005 at 02:06:39PM +1000, Neil Brown wrote:
> On Tuesday March 29, [EMAIL PROTECTED] wrote:
> >
> > Attached is the backout patch, for convenience.
>
> Thanks. I had another look, and think I may be able to see the
> problem. If I'm right, it is a problem with this patch.
>
>
On Wed, Mar 30, 2005 at 02:06:39PM +1000, Neil Brown wrote:
On Tuesday March 29, [EMAIL PROTECTED] wrote:
Attached is the backout patch, for convenience.
Thanks. I had another look, and think I may be able to see the
problem. If I'm right, it is a problem with this patch.
diff -Nru
On Tuesday March 29, [EMAIL PROTECTED] wrote:
>
> Attached is the backout patch, for convenience.
Thanks. I had another look, and think I may be able to see the
problem. If I'm right, it is a problem with this patch.
> diff -Nru a/fs/jbd/commit.c b/fs/jbd/commit.c
> --- a/fs/jbd/commit.c
On Tuesday March 29, [EMAIL PROTECTED] wrote:
Attached is the backout patch, for convenience.
Thanks. I had another look, and think I may be able to see the
problem. If I'm right, it is a problem with this patch.
diff -Nru a/fs/jbd/commit.c b/fs/jbd/commit.c
--- a/fs/jbd/commit.c
24 matches
Mail list logo
