Linux NFS development
 help / color / mirror / Atom feed
From: Joachim Worringen <joachim@ccrl-nece.de>
To: nfs@lists.sourceforge.net
Subject: multiple processes appending data to a single file
Date: Tue, 22 Mar 2005 17:45:56 +0100	[thread overview]
Message-ID: <42404BC4.9070105@ccrl-nece.de> (raw)


Dear NFS experts,

I posted the problem description below to comp.protocols.nfs without a 
real response (only one "it should work" reply - but it doesn't...). So, 
here comes the problem, below are my questions.

Consider the situation of an empty file, and two processes A and B 
concurrently write N bytes to this file via NFS. Process A writes to 
offset 0, and process B lseeks() to offset N to write there. 
Additionally, each process write-locks the range it is accessing before 
actually doing so.

Please note that this is different from the "append-to-file-via-NFS" 
problem that has been discussed to some degree already. Here, each 
process seeks to a known (non-conflicting) position to write its data.

We have observed that for the described access pattern, it can happen 
that after the write operations, the file contains all zeros for offsets 
0..N-1, and the data of process B between N..2N-1. This means, the data 
of process A is lost. Obviously, to comply with POSIX, the write 
operation of process B implied filling up the "gap" between 0 and N-1 
with zeros, overwriting the data of process A (although it locked it's 
range!). This showed up with different NFS server implementations (Linux 
being one of them) and a single NFS client implementation (SUPER-UX) 
which makes us think that this might be a problem of the client. But on 
the other hand, the client is not necessarily involved at all.

Some questions that we have in this context:
- Has anyone experienced this problem?
- Is the expected behaviour defined anywhere? I found nothing related on 
the web, and neither in the NFSv3 RFC.
- Shouldn't the locking prevent the observed behaviour (meaning there's 
a bug somewhere)?
- Which kind of request is generated for such an append situation by the 
NFS client? Does it care at all if there's a gap?
- What does the server do - does it handle this gap in any way, or does 
it rely on the underlying local file system?

  thanks, Joachim

-- 
Joachim Worringen - NEC C&C research lab St.Augustin
fon +49-2241-9252.20 - fax .99 - http://www.ccrl-nece.de


-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

             reply	other threads:[~2005-03-22 16:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-22 16:45 Joachim Worringen [this message]
2005-03-22 16:50 ` multiple processes appending data to a single file Trond Myklebust
2005-03-22 17:39   ` Joachim Worringen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42404BC4.9070105@ccrl-nece.de \
    --to=joachim@ccrl-nece.de \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox