Messages in this thread | | | Date | Fri, 08 Oct 1999 18:41:28 +0200 | From | Manfred Spraul <> | Subject | Re: how to write get_block? |
| |
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, that is serious. > > 3) do not forget f_pos when you implement a synchonization: even > > concurrent reads are not allowed if both use the same file pointer. > > Ditto. It's a separate issue.
These are 2 pending problems which must be fixed before 2.4
If you fix them, then you will add synchonization to sys_write(), and raw-io will be affected since raw-io is accessed through sys_write() to a special character device driver.
Other pending problems are O_APPEND, mandantory file locks.
Eg mandantory file locks: process A: backup. It make multi-megabyte read operations. During these long operations, the kernel schedules around.
process B: uses the database. Mandantory file locks. it calls lock(), read(), write(), write(), unlock(). ^^^ kernel schedules back to process A, it reads the data.
--> data corruption. Mandantory file locks must not return if there are pending read operations in the affected area.
> > Eg I'm pretty sure that Stephen will not like it if raw-io is slowed > > down by a multiple reader-single writer synchonization. > > Erm? Writer access is for truncate() and I don't see where the raw-io > comes into the picture.
Not yet, but if you fix all synchonization, then it will come into the picture.
> Huh? It's not a sys_write(), it's generic_file_write(). Pipes do not come > even close to that place.
Not yet, but after you have fixed f_pos, it will come into the picture.
> And I'm talking about 2.3 - 2.2 is _way_ too > different. I know that, but 2.3 is broken, 2.2 is ugly. I wanted to say that we should NOT make the same fault again. Flags are needed.
-- Manfred
- 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/
| |