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
next 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