>> I just spotted this in the NFSv2 spec (rfc1094)
>>
>> Writes "data" beginning "offset" bytes from the beginning of
>> "file". The first byte of the file is at offset zero. If the
>> reply "status" is NFS_OK, then the reply "attributes" contains
>> the attributes of the file after the write has completed. The
>> write operation is atomic. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data
>> from this "WRITE" will not be mixed with data from another
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> client's "WRITE". ^^^^^^^^^^^^^^^^
>>
>> NFSv2's requirements are stricter -- so I guess knfsd has to
>> handle this by locking the inode during an NFSv2 write. Is
>> this done and does anyone care?
> It isn't done and any locking works only if everybody use it.
> Probably using rwlock-style semantics (modulo sleeping, indeed
> - you don't want spinlocks here) would be the right thing. Then
> we have write() as reader, knfsd write() as writer and quite
> probably truncate() as writer too.
Please also recall that NFSv2 assumes that all writes are performed
synchronously on the server (all data and metadata is immediately
flushed to disk). In principle, once the NFS_OK is received by the
client, I'm allowed to attack my server with a pickaxe without
risking any data loss (unless the disk spills its guts).
As long as we violate the synchronicity assumption strict adherence to
the rule of atomicity of writes becomes a largely academic issue.
For NFSv3, things are of course different, since there the NFS_COMMIT
instruction exists in order to trigger the flushing to disk.
Cheers,
Trond
-
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/