On Thu, 21 Dec 2000, Linus Torvalds wrote:
>
>
> On Fri, 22 Dec 2000, Jan Niehusmann wrote:
> >
> > This is the result - against test12-pre7, but works well with
> > test13-pre3:
>
> This looks bogus.
It is bogus. My apologies.
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Dec 21, 2000 at 05:01:00PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 22 Dec 2000, Jan Niehusmann wrote:
> >
> > The test I did initially was the following:
> >
> > if(!atomic_read(>b_count) &&
> > (destroy_dirty_buffers || !buffer_dirty(bh))
> > && ! (bh->b_page &&
On Fri, 22 Dec 2000, Jan Niehusmann wrote:
>
> The test I did initially was the following:
>
> if(!atomic_read(>b_count) &&
> (destroy_dirty_buffers || !buffer_dirty(bh))
> && ! (bh->b_page && bh->b_page->mapping)
> )
>
> That is, I was explicitely checking for a mapped
On Thu, Dec 21, 2000 at 04:37:30PM -0800, Linus Torvalds wrote:
> This looks bogus.
It may be - I just did what Al told me without really understanding it ;-)
The test I did initially was the following:
if(!atomic_read(>b_count) &&
(destroy_dirty_buffers || !buffer_dirty(bh))
On Fri, 22 Dec 2000, Jan Niehusmann wrote:
>
> This is the result - against test12-pre7, but works well with
> test13-pre3:
This looks bogus.
You can't test "bh->b_next!=0", because that is entirely meaningless.
b_next can be NULL either because the buffer isn't hashed, or because the
The file corruption I reported on Dec 6 is still there in test13-pre3.
(I can only reproduce it easily with the ext2 online resizing patches,
but I really don't think it is caused by them)
The corruption happens if invalidate_buffers calls put_last_free() on
buffers that belong to mapped pages.
The file corruption I reported on Dec 6 is still there in test13-pre3.
(I can only reproduce it easily with the ext2 online resizing patches,
but I really don't think it is caused by them)
The corruption happens if invalidate_buffers calls put_last_free() on
buffers that belong to mapped pages.
On Fri, 22 Dec 2000, Jan Niehusmann wrote:
This is the result - against test12-pre7, but works well with
test13-pre3:
This looks bogus.
You can't test "bh-b_next!=0", because that is entirely meaningless.
b_next can be NULL either because the buffer isn't hashed, or because the
buffer
On Thu, Dec 21, 2000 at 04:37:30PM -0800, Linus Torvalds wrote:
This looks bogus.
It may be - I just did what Al told me without really understanding it ;-)
The test I did initially was the following:
if(!atomic_read(bh-b_count)
(destroy_dirty_buffers || !buffer_dirty(bh))
!
On Fri, 22 Dec 2000, Jan Niehusmann wrote:
The test I did initially was the following:
if(!atomic_read(bh-b_count)
(destroy_dirty_buffers || !buffer_dirty(bh))
! (bh-b_page bh-b_page-mapping)
)
That is, I was explicitely checking for a mapped page. It worked
On Thu, 21 Dec 2000, Linus Torvalds wrote:
On Fri, 22 Dec 2000, Jan Niehusmann wrote:
This is the result - against test12-pre7, but works well with
test13-pre3:
This looks bogus.
It is bogus. My apologies.
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Dec 07, 2000 at 05:26:46PM -0500, Alexander Viro wrote:
> That invalidate_buffers() should leave the unhashed ones alone. If it can't
> be found via getblk() - just leave it as is.
>
> IOW, let it skip bh if (bh->b_next == NULL && !destroy_dirty_buffers).
> No warnings needed - it's a
On Thu, 7 Dec 2000, Udo A. Steinberg wrote:
> Jan Niehusmann wrote:
> >
> > The following patch actually prevents the corruption I described.
> >
> > I'd like to hear from the people having problems with hdparm, if it helps
> > them, too.
>
> Yes, it prevents the issue.
>
> > Please note
Jan Niehusmann wrote:
>
> The following patch actually prevents the corruption I described.
>
> I'd like to hear from the people having problems with hdparm, if it helps
> them, too.
Yes, it prevents the issue.
> Please note that the patch circumvents the problem more than it fixes it.
> The
The following patch actually prevents the corruption I described.
I'd like to hear from the people having problems with hdparm, if it helps
them, too.
Please note that the patch circumvents the problem more than it fixes it.
The true fix would invalidate the mappings, but I don't know how to do
The following patch actually prevents the corruption I described.
I'd like to hear from the people having problems with hdparm, if it helps
them, too.
Please note that the patch circumvents the problem more than it fixes it.
The true fix would invalidate the mappings, but I don't know how to do
Jan Niehusmann wrote:
The following patch actually prevents the corruption I described.
I'd like to hear from the people having problems with hdparm, if it helps
them, too.
Yes, it prevents the issue.
Please note that the patch circumvents the problem more than it fixes it.
The true
On Thu, 7 Dec 2000, Udo A. Steinberg wrote:
Jan Niehusmann wrote:
The following patch actually prevents the corruption I described.
I'd like to hear from the people having problems with hdparm, if it helps
them, too.
Yes, it prevents the issue.
Please note that the patch
On Thu, Dec 07, 2000 at 05:26:46PM -0500, Alexander Viro wrote:
That invalidate_buffers() should leave the unhashed ones alone. If it can't
be found via getblk() - just leave it as is.
IOW, let it skip bh if (bh-b_next == NULL !destroy_dirty_buffers).
No warnings needed - it's a normal
19 matches
Mail list logo
