All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: ext3 and SPEC SFS Run rules.
Date: Mon, 26 Jul 2004 00:03:13 -0700	[thread overview]
Message-ID: <20040726000313.3fbf8403.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0407221933520.2152-100000@einstein.homenet>

Tigran Aivazian <tigran@aivazian.fsnet.co.uk> wrote:
>
> I have a simple question --- does ext3 conform to the SPEC SFS Run rules 
>  with default mount options or does one need to force the correct 
>  behaviour by mounting in some "special" way?. Here is the URL for the 
>  rules:
> 
>    http://www.spec.org/sfs97r1/docs/runrules.html
> 
>  In particular, the bit that is worrying me is:
> 
>    For NFS Version 3, the server adheres to the protocol specification. In 
>    particular the requirement that for STABLE write requests and COMMIT 
>    operations the NFS server must not reply to the NFS client before any 
>    modified file system data or metadata, with the exception of access times, 
>    are written to stable storage for that specific or related operation. 
>    See RFC 1813, NFSv3 protocol specification for a definition of STABLE 
>    and COMMIT for NFS write requests.
> 
>  As far as I can see from nfsd source this means:
> 
>  a) write with 'stable' flag set does a f_op->write() with O_SYNC.
> 
>  b) COMMIT3 just means f_op->fsync().
> 
>  So, the question is really --- do ext3 O_SYNC write and fsync require some 
>  special mount options to work _properly_ or are they fine by default?
> 
>  Looking at ext3_sync_file() it seems OK by default.
> 
>  However, looking at ext3 ->write() operation it seems to forcibly commit 
>  only if it is mounted with EXT3_MOUNT_JOURNAL_DATA option (or if it is not 
>  a regular file or if EXT3_JOURNAL_DATA_FL inode flag is set).

ext3 should be fully syncing data and metadata for both fsync() and O_SYNC
writes in all three journalling modes.  If not, that's a big bug.

  reply	other threads:[~2004-07-26  7:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-22 18:49 ext3 and SPEC SFS Run rules Tigran Aivazian
2004-07-26  7:03 ` Andrew Morton [this message]
2004-07-26  9:12   ` Tigran Aivazian
2004-07-26  9:18     ` Tigran Aivazian
2004-07-28 21:00       ` Andreas Dilger
2004-07-26 19:57     ` Theodore Ts'o
2004-07-26 20:01     ` Andrew Morton
2004-07-26 23:00       ` Neil Brown
2004-07-26 23:45         ` Brian Pawlowski

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=20040726000313.3fbf8403.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tigran@aivazian.fsnet.co.uk \
    /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.