Commenting only on a subset of Alexander's comments:
On Fri, Oct 08, 1999 at 12:35:53PM -0400, Alexander Viro wrote:
> More or less random comments/questions:
> 4) I still think that indirect blocks may go into the page cache - that
> would further simplify truncate(). OTOH the method
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
Manfred Spraul wrote:
> I'll check the POSIX standard, perhaps we can just reject mmap() or
> file-locks in this situation.
I couldn't find it in the POSIX standart, but at least some UNIXes don't
allow it:
http://hoth.stsci.edu/man/man2/fcntl.html: (sun unix)
> The fcntl() function will fail i
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:
> _That_ protection should be enough to avoid several callers of
> write() messing with each other.
IIRC NfsV2 guarantees atomicity of write operation.
--
Manfred
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 different things to protect. E.g
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 ar
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
On Fri, 8 Oct 1999, Alexander Viro wrote:
>That's it. write() does lock the page before writing to it/allocating new
>blocks/etc. _That_ protection should be enough to avoid several callers of
>write() messing with each other.
Except the fact that two writers writing 100byte each one will produc
> 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.
> I
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.
Alexander Viro wrote:
> > 1) overlapping concurrent write operations violate Nfsv2.
>
> Yes,
> yep we knew about this problem ... it's not quite an easy hack though.
> Putting the directory block cache (and symlink block cache) into the page
> cache would be the preferred method - this would also clean up the code
> alot i think.
If you knew about it, why didn't you fix it?? (or impleme
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 appr
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 the page cache and do
> block_flush(). I'ld rath
On Fri, 8 Oct 1999, Andrea Arcangeli wrote:
> On Fri, 8 Oct 1999, Alexander Viro wrote:
>
> >AFAICS. The next thing I'm going to do is a (dumb) implementation of
> >blocking rwlocks. write() being reader and truncate() - writer.
>
> To make the design of the code simpler write(2) should be a
On Fri, 8 Oct 1999, Mikulas Patocka wrote:
>How do you manage freeing buffers on rmdir? I don't see any bforget there.
>If you don't free buffers pointing to deallocated space, it can cause data
>corruption.
Replacing all bforget with brelse can't harm. It will only be far slower
as you'll risk
On Fri, 8 Oct 1999, Alexander Viro wrote:
>AFAICS. The next thing I'm going to do is a (dumb) implementation of
>blocking rwlocks. write() being reader and truncate() - writer.
To make the design of the code simpler write(2) should be a writer too.
All the VM checks i_size without any lock. So
On Fri, 8 Oct 1999, Mikulas Patocka wrote:
> You have a directory and change something in it - there are dirty hashed
> buffers covering directory.
>
> You erase that directory - as there is no bforget, there are still dirty
> hashed buffers.
>
> You alloc file at that place. Buffers contain
> > You have a directory and change something in it - there are dirty hashed
> > buffers covering directory.
> >
> > You erase that directory - as there is no bforget, there are still dirty
> > hashed buffers.
> >
> > You alloc file at that place. Buffers containing former directory are
> > flu
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
> On what? ITYM truncate(), right? Metadata doesn't end up in the page
> cache, so... ->flushpage() set to block_flushpage() should be OK, but it
> will not be enough. All stuff with truncate()/write() is racey right now,
> AFAICS. The next thing I'm going to do is a (dumb) implementation of
> blo
On Fri, 8 Oct 1999, Mikulas Patocka wrote:
> > > 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
> > 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 t
23 matches
Mail list logo
