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