Sheesh... Yes, you are right. It was not a problem with the old buffer
cache, but now... Arrgh. Races in truncate(), film at 11. Pheeewww...
Unless I'm seriously misunderstanding what happens you've just dug out a
race in ext2. It doesn't do bforget() on the data blocks in directories.
If
On Fri, 8 Oct 1999, Ingo Molnar wrote:
On Fri, 8 Oct 1999, Alexander Viro wrote:
Stephen, Ingo, could you look at the stuff above? Methink it means that we
either must separate ext2_truncate() for directories (doing bforget() on
the data blocks) _or_ put the directory blocks into
Alexander Viro wrote:
On Fri, 8 Oct 1999, Manfred Spraul wrote:
I think it's wrong to fix synchonization on a problem-by-problem basis:
VFS synchonization for read()/write()/truncate()/file lock's is broken,
and I would try to find one solution instead of patch-work.
There are
Andrea Arcangeli wrote:
I really don't think it make sense to let write(2) to be SMP parallel as
it would be unreliable and thus useless. So basically allowing more writes
to enter the critical section looks an useless improvement and lose of
robustness to me.
a) we must allow concurrent
Hi.
I'm porting my HPFS driver to 2.3.18 and I don't know how to write
get_block properly. When user does lseek(far beyond file end) and
write(), get_block must allocate a lot of sectors and clear them (HPFS
doesn't support holes). The question is: what call should I use to
clear
On Fri, 8 Oct 1999, Manfred Spraul wrote:
Alexander Viro wrote:
All stuff with truncate()/write() is racey right now,
AFAICS. The next thing I'm going to do is a (dumb) implementation of
blocking rwlocks. write() being reader and truncate() - writer.
IMHO that's the wrong approach:
On Fri, 8 Oct 1999, Manfred Spraul wrote:
I couldn't find it in the POSIX standart, but at least some UNIXes don't
allow it:
Sure. We are kinda-sorta preventing it too. But there is a windows when
both the shared mmap() and lockf() may pass (if mmap() comes first,
overlaps the memory area
Alexander Viro wrote:
All stuff with truncate()/write() is racey right now,
AFAICS. The next thing I'm going to do is a (dumb) implementation of
blocking rwlocks. write() being reader and truncate() - writer.
IMHO that's the wrong approach:
1) overlapping concurrent write operations violate
