"Eric W. Biederman" wrote:
Hans Reiser [EMAIL PROTECTED] writes:
I feel we should encourage Linus to allow the following:
* unions in struct buffer_head and struct page containing filesystem specific
fields comparable to the union in struct inode.
No.
In struct buffer_head I don't
Hi,
On Mon, 11 Oct 1999 11:12:01 -0400 (EDT), Alexander Viro
[EMAIL PROTECTED] said:
I began screwing around the truncate() stuff and the following is
a status report/request for comments:
a) call of -truncate() method (and vmtruncate()) had been moved
into the notify_change().
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote:
Hi,
On Tue, 12 Oct 1999 09:37:28 -0400 (EDT), Alexander Viro
[EMAIL PROTECTED] said:
Rationale was:
a) get rid of code duplication and get all calls of -truncate()
into the same place.
b) make it in the same place that
Hi,
On Sat, 9 Oct 1999 23:53:01 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] said:
What I said about bforget in my old email is still true. The _only_ reason
for using bforget instead of brelse is to get buffer performances (that in
2.3.x are not so interesting as in 2.2.x as in 2.3.x
Hi,
On 11 Oct 1999 17:58:54 -0500, [EMAIL PROTECTED] (Eric W. Biederman)
said:
What about adding to the end of ext2_alloc_block:
bh = get_hash_table(inode-i_dev, result, inode-i_sb-s_blocksize);
/* something is playing with our fresh block, make them stop. ;-) */
if (bh) {
if
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote:
changes. The ext2 truncate code is really, really careful to provide
I was _not_ talking about ext2 at all. I was talking about the bforget and
brelse semantics. As bforget fallback to brelse you shouldn't expect
bforget to really destroy the
On 11 Oct 1999, Eric W. Biederman wrote:
What about adding to the end of ext2_alloc_block:
It's _equally_ slow. Do you seen my patch? I prefer to do the query at the
higher lever to save cpu cache.
Andrea
Hi,
On Tue, 12 Oct 1999 15:39:35 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] said:
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote:
changes. The ext2 truncate code is really, really careful to provide
I was _not_ talking about ext2 at all. I was talking about the bforget and
brelse
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote:
Umm, your last proposal was to do a hash lookup on each new page cache
buffer mapping. That is a significant performance cost, which IMHO is
not exactly the right direction either. :)
It's not obvious that the only thing to consider are
G'day!
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote:
...
Andrea, you are just trying to relax carefully designed buffer cache
semantics which are relied upon by the current filesystems. Saying it
is a trick doesn't help matters much.
Andrea's right in that the semantics make it far too
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans Reiser
"Stephen C. Tweedie" wrote:
Hi,
On Tue, 12 Oct 1999 03:14:03 +0400, Hans Reiser [EMAIL PROTECTED] said:
Hans, you didn't mention a journal call that happens on sync, or
11 matches
Mail list logo
