All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.