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

"Stephen C. Tweedie" wrote:
> 
> 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.
> 

OK, that makes sense.  Thanks.  The `mount' and `chattr' manpages
need updating...

So shall we try to nail this down?  Synchronous mounts and chattr +S
provide synchronous semantics for directory contents, diretory metadata
and directory inodes only.  And fsync() will write out a file's data,
metadata and inode?

If this is correct then there are a few places where ext2 is
syncing stuff unnecessarily - file indirect blocks, etc.  Not
very important at this stage I guess.

-

  reply	other threads:[~2001-11-15 22:03 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
2001-11-15 22:02   ` Andrew Morton [this message]
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=3BF43B8E.51A809D1@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    --cc=sct@redhat.com \
    /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.