"Jeff V. Merkey" wrote:
>
> Linus,
>
> I don't know why it was done this way, but it appears that unless buffer
> heads are allocated from the buffer cache, submitting your own via
> commit_write() doesn't seem to work. perhaps you could enlighten me as
> to why buffers aren't getting flushed as they should. after stepping
> though the code, it appears that external buffer heads cannot be used
> with the page cache.
>
> I've created an alternate implementation that works using my own LRU
> (which is less than ieal), and have also "hacked" a 2.3.99pre-5 kernel
> to expose the "static" functions from the buffer cache so I can obtain
> buffer_heads from the Linux buffer cache and pass them to calls to
> commit_write() -- this works great, except when I've got a lot of
> mirrors on the system with multiple volumes this really sucks up ***A
> LOT*** of memory as buffer heads.
>
> The obvious and simple solution is to provide a VARIABLE SECTOR LENGTH
> buffer head to ll_rw_block() without the onerous "block size
> 512-1024-2048-4096" restriction that requires TONS of memory to be
> NEEDLESSLY sucked up and used for buffer head chains, when a simple
> field (like b_size) is already present to tell the driver the block
> size. I don't understand why it wasn't implemented this way in the
> first place -- such would seem intuitive to me.
>
> I don't know how ugly such a change would be, or how many drivers it
> would bust, but it would certainly make it a lot easier moving forward
> for all kinds of performance optimizations. At present, I've had to
> implement an extra flush daemon to flush the dirty pages with mirroring
> enabled. I would rather have a buffer head that will:
>
> 1). allow variable length sector writes/reads up to 128 sectors in a
> run.
> 2). allow logical LBA (vs. physical) that will call bmap() prior to
> write and support multiple locations for a single page to be written.
> 3). allow externally allocated buffer heads to be posted via
> commit_write() and actually get flushed.
>
> The semantic of having a dirty page that is flushed in a lazy manner was
> a **GREAT** idea. I just wish it worked without the incestuous
> dependencies with the buffer cache (or at a minimum, provide a way for
> external consumers to post buffer heads that get written).
>
> :-)
>
> Jeff Merkey
> TRG, Inc.
BTW. If it can be allowed to support this, I'll throw out my LRU and
use yours instead (because yours will then support asynch mirroring
without a lot of fuss).
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:19 EST