On Tue, 19 Dec 2000, Daniel Phillips wrote:
> Marcelo Tosatti wrote:
> >
> > On Mon, 18 Dec 2000, Stephen C. Tweedie wrote:
> >
> > > Hi,
> > >
> > > On Sun, Dec 17, 2000 at 12:38:17AM -0200, Marcelo Tosatti wrote:
> > > > On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
> > > >
> > > > Stephen,
In article <[EMAIL PROTECTED]> you wrote:
>> I think the semantics of the filesystem specific ->flush and ->writepage
>> are not the same.
>>
>> Is ok for filesystem specific writepage() code to sync other "physically
>> contiguous" dirty pages with reference to the one requested by
>> writepage(
Marcelo Tosatti wrote:
>
> On Mon, 18 Dec 2000, Stephen C. Tweedie wrote:
>
> > Hi,
> >
> > On Sun, Dec 17, 2000 at 12:38:17AM -0200, Marcelo Tosatti wrote:
> > > On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
> > >
> > > Stephen,
> > >
> > > The ->flush() operation (which we've been discussing
On Mon, 18 Dec 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Sun, Dec 17, 2000 at 12:38:17AM -0200, Marcelo Tosatti wrote:
> > On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
> >
> > Stephen,
> >
> > The ->flush() operation (which we've been discussing a bit) would be very
> > useful now (mainl
Hi,
On Sun, Dec 17, 2000 at 12:38:17AM -0200, Marcelo Tosatti wrote:
> On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
>
> Stephen,
>
> The ->flush() operation (which we've been discussing a bit) would be very
> useful now (mainly for XFS).
>
> At page_launder(), we can call ->flush() if the gi
Hi,
On Sat, Dec 16, 2000 at 07:08:02PM -0600, Russell Cattelan wrote:
> > There is a very clean way of doing this with address spaces. It's
> > something I would like to see done properly for 2.5: eliminate all
> > knowledge of buffer_heads from the VM layer. It would be pretty
> > simple to re
On Sat, 16 Dec 2000, Russell Cattelan wrote:
> >
> I'm curious about this.
> Does the mean reiserFS is doing all of it's own buffer management?
>
> This would seem a little redundant with what is already in the kernel?
>
For metadata only reiserfs does its own write management. The buffers
co
On Fri, 15 Dec 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, Dec 15, 2000 at 02:00:19AM -0500, Alexander Viro wrote:
> > On Thu, 14 Dec 2000, Linus Torvalds wrote:
> >
> > Just one: any fs that really cares about completion callback is very likely
> > to be picky about the requests orderin
"Stephen C. Tweedie" wrote:
> Hi,
>
> On Fri, Dec 15, 2000 at 02:00:19AM -0500, Alexander Viro wrote:
> > On Thu, 14 Dec 2000, Linus Torvalds wrote:
> >
> > Just one: any fs that really cares about completion callback is very likely
> > to be picky about the requests ordering. So sync_buffers() i
Chris Mason wrote:
> On Fri, 15 Dec 2000, Alexander Viro wrote:
>
> > Just one: any fs that really cares about completion callback is very likely
> > to be picky about the requests ordering. So sync_buffers() is very unlikely
> > to be useful anyway.
> >
> Somewhat. I guess there are at least tw
Alexander Viro wrote:
> On Thu, 14 Dec 2000, Linus Torvalds wrote:
>
> > Good point.
> >
> > This actually looks fairly nasty to fix. The obvious fix would be to not
> > put such buffers on the dirty list at all, and instead rely on the VM
> > layer calling "writepage()" when it wants to push out
Linus Torvalds wrote:
> On Thu, 14 Dec 2000, Russell Cattelan wrote:
> >
> > Ok one more wrinkle.
> > sync_buffers calls ll_rw_block, this is going to have the same problem as
> > calling ll_rw_block directly.
>
> Good point.
>
> This actually looks fairly nasty to fix. The obvious fix would be t
On Sat, 16 Dec 2000, Linus Torvalds wrote:
> Your patch looks fine, although I'd personally prefer this one even more:
>
Yes, that looks better and works here.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Pleas
On Sat, 16 Dec 2000, Chris Mason wrote:
>
> In other words, after calling reiserfs_get_block, the buffer might be
> mapped and uptodate, with no i/o required in block_read_full_page
>
> The following patch to block_read_full_page fixes things for me, and seems
> like a good idea in general. I
On Fri, 15 Dec 2000, Linus Torvalds wrote:
[ writepage for anon buffers ]
>
> It might be 10 lines of change, and obviously correct.
>
I'll give this a try, it will be interesting regardless of if it is simple
enough for kernel inclusion.
On a related note, I hit a snag porting reiserfs int
On Sat, 16 Dec 2000, Jeff Chua wrote:
>
> > Now, I also agree that we should be able to clean this up properly for
> > 2.5.x, and actually do exactly this for the anonymous buffers, so that
> > the VM no longer needs to worry about buffer knowledge, and fs/buffer.c
> > becomes just another user
> Now, I also agree that we should be able to clean this up properly for
> 2.5.x, and actually do exactly this for the anonymous buffers, so that
> the VM no longer needs to worry about buffer knowledge, and fs/buffer.c
> becomes just another user of the writepage functionality. That is not
> all
In article <[EMAIL PROTECTED]>,
Stephen C. Tweedie <[EMAIL PROTECTED]> wrote:
>
>> What we really need is a way for VFS/VM to pass the pressure on filesystem.
>> That's it. If fs wants unusual completions for requests - let it have its
>> own queueing mechanism and submit these requests when it fi
Hi,
On Fri, Dec 15, 2000 at 02:00:19AM -0500, Alexander Viro wrote:
> On Thu, 14 Dec 2000, Linus Torvalds wrote:
>
> Just one: any fs that really cares about completion callback is very likely
> to be picky about the requests ordering. So sync_buffers() is very unlikely
> to be useful anyway.
>
On Fri, 15 Dec 2000, Alexander Viro wrote:
> Just one: any fs that really cares about completion callback is very likely
> to be picky about the requests ordering. So sync_buffers() is very unlikely
> to be useful anyway.
>
Somewhat. I guess there are at least two ways to do it. First flush
On Thu, 14 Dec 2000, Linus Torvalds wrote:
> Good point.
>
> This actually looks fairly nasty to fix. The obvious fix would be to not
> put such buffers on the dirty list at all, and instead rely on the VM
> layer calling "writepage()" when it wants to push out the pages.
> That would be the
On Thu, 14 Dec 2000, Russell Cattelan wrote:
>
> Ok one more wrinkle.
> sync_buffers calls ll_rw_block, this is going to have the same problem as
> calling ll_rw_block directly.
Good point.
This actually looks fairly nasty to fix. The obvious fix would be to not
put such buffers on the dirty
On Thu, 14 Dec 2000, Russell Cattelan wrote:
>
> So one more observation in
> filemap_sync_pte
>
> lock_page(page);
> error = filemap_write_page(page, 1);
> -> UnlockPage(page);
> This unlock page was removed? is that correct?
Yes. The "writepage" thing changed: "struct file" disappeared (
In article <[EMAIL PROTECTED]>,
Russell Cattelan <[EMAIL PROTECTED]> wrote:
>This would seem to be an error on the part of ll_rw_block.
>Setting b_end_io to a default handler without checking to see
>a callback has already been defined defeats the purpose of having
>a function op.
No.
It just m
24 matches
Mail list logo
