public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Neil Brown <neilb@cse.unsw.edu.au>,
	Stephen Tweedie <sct@redhat.com>
Subject: Re: synchronous mounts
Date: Thu, 15 Nov 2001 21:45:25 +0000	[thread overview]
Message-ID: <20011115214525.C14221@redhat.com> (raw)
In-Reply-To: <3BF376EC.EA9B03C8@zip.com.au>
In-Reply-To: <3BF376EC.EA9B03C8@zip.com.au>; from akpm@zip.com.au on Thu, Nov 15, 2001 at 12:03:57AM -0800

Hi,

On Thu, Nov 15, 2001 at 12:03:57AM -0800, Andrew Morton wrote:
> Linux is not syncing write() data for files on synchronously mounted
> filesystems, and it isn't syncing write() data for ext2/3 files which
> are operating under `chattr +S'.

In the past, chattr +S and mount -o sync always resulted in sync
metadata with no guarantees about data. 

I'm not sure this makes much sense, but it's what has always happened.
For directories, the behaviour is fine, in particular as it gives us
the same directory sync consistency semantics as synchronous BSD UFS.  

It's not clear to me that chattr/mount sync options make _any_ sense
for regular file metadata.  Rather than tightening up the semantics,
I'd actually prefer to restrict them so that they only apply to
directories.  Users who set the sync bits are usually doing so for
applications like MTAs where it's directory syncing which is
what matters: the apps typically fsync the files themselves, anyway.
 
> Really, generic_osync_inode() needs to be front-ended by
> an inode_operations method.

Yes.

Cheers,
 Stephen

  reply	other threads:[~2001-11-15 21:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-15  8:03 synchronous mounts Andrew Morton
2001-11-15 21:45 ` Stephen C. Tweedie [this message]
2001-11-15 22:02   ` Andrew Morton
2001-11-15 23:05     ` Stephen C. Tweedie
2001-11-16  0:19   ` Jeff Garzik
2001-11-16  8:33     ` Andrew Morton
2001-11-16 10:47       ` Matthias Andree
2001-11-16 12:28     ` Stephen C. Tweedie
2001-11-16 13:28       ` Jeff Garzik
2001-11-16 13:37       ` Jeff Garzik
2001-11-16 22:40       ` Matthias Andree
2001-11-16  3:07   ` Neil Brown
2001-11-17  7:13     ` Andrew Morton

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=20011115214525.C14221@redhat.com \
    --to=sct@redhat.com \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    /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