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

Hi,

On Thu, Nov 15, 2001 at 02:02:54PM -0800, Andrew Morton wrote:
> 
> 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?

Sounds sane.  UFS sync mounts also update the inode bitmaps
synchronously, and in order, so that they can tell exactly when an
inode is valid.  I guess that we don't need that, at least on ext2,
since the i_dtime gives us the necessary information automatically.

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

It's important for people running MTAs which expect dir sync
behaviour: admins have to pay the performance cost of all file updates
being sync as well as the directory updates if they enable chattr +S
on the dir.

--Stephen

  reply	other threads:[~2001-11-15 23:05 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
2001-11-15 23:05     ` Stephen C. Tweedie [this message]
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=20011115230514.T1914@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 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.