lkml.org 
[lkml]   [2001]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] generic IO write clustering
On Sat, Jan 20, 2001 at 01:24:40PM -0200, Marcelo Tosatti wrote:
> In case the metadata was not already cached before ->cluster() (in this
> case there is no disk IO at all), ->cluster() will cache it avoiding
> further disk accesses by writepage (or writepages()).

True. But you have to go through ext2_get_branch (under the big kernel
lock) - if we can do only one logical->physical block translations,
why doing it multiple times?

> > Another thing I dislike is that the flushing gets more complicated with
> > yout VM-level clustering. Now (and with my appropeach I'll describe
> > below) flushing is write it out now and do whatever you else want,
> > with you design it is 'find out pages beside this page in write out
> > a bunch of them' - much more complicated. I'd like it abstracted out.
>
> I dont see your point here. What I'm missing?

It's just a matter of taste.
(I thought it was clear enough that there is no technical advantage...)

> [...]
>
> IMHO replicating the code is the worst thing.

This does not replicated the code. The 'normal' filesystems share the
code, and the special filesystems want to their own clustering anyway.
(See the discussion on xfs-devel yesterday).

Christoph

--
Whip me. Beat me. Make me maintain AIX.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:02    [W:0.098 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site