lkml.org 
[lkml]   [1999]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch] [possible race in ext2] Re: how to write get_block?
From
Date
"Stephen C. Tweedie" <sct@redhat.com> writes:

> Hi,
>
> On Sun, 10 Oct 1999 16:57:18 +0200 (CEST), Andrea Arcangeli
> <andrea@suse.de> said:
>
> > My point was that even being forced to do a lookup before creating
> > each empty buffer, will be still faster than 2.2.x as in 2.3.x the hash
> > will contain only metadata. Less elements means faster lookups.
>
> The _fast_ quick fix is to maintain a per-inode list of dirty buffers
> and to invalidate that list when we do a delete. This works for
> directories if we only support truncate back to zero --- it obviously
> gets things wrong if we allow partial truncates of directories (but why
> would anyone want to allow that?!)
>
> This would have minimal performance implication and would also allow
> fast fsync() of indirect block metadata for regular files.

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 (buffer_dirty(bh)) {
mark_buffer_clean(bh);
wait_on_buffer(bh);
}
bforget(bh);
}

This is in a relatively slow/uncommon path and also catches
races if indirect blocks are allocated to a file, instead
of just directory syncs.

Ultimately we really want to have indirect blocks, and
the directory in the page cache as it should result in
more uniform code, and faster partial truncates (as well as faster
syncs).

Eric

-
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/

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