From: Matthias Andree <matthias.andree@stud.uni-dortmund.de>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine for directories on NFS mounts
Date: Mon, 15 Jul 2002 15:35:07 +0200 [thread overview]
Message-ID: <20020715133507.GF32155@merlin.emma.line.org> (raw)
In-Reply-To: <Pine.LNX.3.95.1020715084232.22834A-100000@chaos.analogic.com>
On Mon, 15 Jul 2002, Richard B. Johnson wrote:
> These are things that should be addressed rather than flamed-
> away. I think that the intent of fsync() on a file is to make
> certain that it is on the physical media in a state from which
> it can be accessed after a crash. If this is the intent, then
> playing games with individual directories is not useful and
> fsync() on the read/write file-descriptor actually updating the
> file should be sufficient.
We had a similar discussion along the lines of an MTA roughly a year
ago, but without your (unquoted) objection that fsync() on a fiel
without write permit should be impossible.
The essence was that Linux 2.4 ext3fs and reiserfs guarantee that on
fsync(), the file is recoverable from the place it was created, 2.2 was
halfway there; but beware: only data=ordered or data=journal (in ext3fs,
as beta patch for reiserfs from
ftp.suse.com:/pub/people/mason/patches/data-logging/ <- from memory))
will guarantee that your file contents are recoverable.
This does not constitute any statement on JFS or XFS. I'm unaware of
their characteristics in fsync and directory update issues.
That aside, it would really useful to get this "hog a writer" issue
ironed out either way, and that the illogical "fsync() a O_RDONLY" file
be resolved somehow.
For the data of users not acquainted with kernel intrinsics, the way
things are now are most dangerous, and I'd really ask that Andrew
Morton's dirsync() patches (where still necessary) and tool patches
(chattr, mount) be deployed NOW and that -o dirsync (call it noasync for
compatibility) be the default. A safety-speed tradeoff should only
sacrifice safety at the explicit request and mke2fs should be told to
generate ext3fs by default NOW.
The argumentation that Linux leaves the choice of when to sync directory
data to the application is nice, but not more, and having this as tuning
option is fine, but to quote Wietse Venema "it's interesting to see that
out of the box, Linux handles logging more securely (sync writes) than
email (async directory updates)". And right he is.
Is fsync()ing directories any portable?
-- archived at: http://groups.google.com/groups?selm=89uj5c%242h2s%241%40FreeBSD.csie.NCTU.edu.tw&oe=utf-8&output=gplain
--
Matthias Andree
next prev parent reply other threads:[~2002-07-15 13:32 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020715075221.GC21470@uncarved.com>
2002-07-15 12:45 ` Richard B. Johnson
2002-07-15 13:35 ` Matthias Andree [this message]
[not found] ` <mit.lcs.mail.linux-kernel/20020715133507.GF32155@merlin.emma.line.org>
2002-07-15 14:49 ` Patrick J. LoPresti
2002-07-15 15:18 ` Matthias Andree
[not found] ` <mit.lcs.mail.linux-kernel/20020715151833.GA22828@merlin.emma.line.org>
2002-07-15 16:10 ` Patrick J. LoPresti
2002-07-15 18:16 ` Matthias Andree
[not found] ` <mit.lcs.mail.linux-kernel/20020715181650.GA20665@merlin.emma.line.org>
2002-07-15 18:56 ` Patrick J. LoPresti
2002-07-15 20:50 ` Matthias Andree
2002-07-15 16:16 ` Alan Cox
2002-07-15 15:19 ` Matthias Andree
2002-07-15 16:45 ` Alan Cox
2002-07-15 15:38 ` Patrick J. LoPresti
2002-07-15 16:55 ` Alan Cox
2002-07-15 15:29 ` [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine fordirectories " Sandy Harris
2002-07-15 20:17 ` [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine for directories " Patrick J. LoPresti
2002-07-16 1:40 ` jw schultz
2002-07-15 15:20 ` Bill Rugolsky Jr.
2002-07-15 15:35 ` Matthias Andree
2002-07-15 16:14 ` Bill Rugolsky Jr.
2002-07-09 13:49 Trond Myklebust
2002-07-09 14:06 ` Richard B. Johnson
2002-07-09 14:08 ` Trond Myklebust
2002-07-09 15:06 ` Richard B. Johnson
2002-07-09 16:56 ` Alan Cox
2002-07-09 17:22 ` Richard B. Johnson
2002-07-09 19:11 ` Alan Cox
2002-07-09 19:13 ` Richard B. Johnson
2002-07-09 19:59 ` Alan Cox
2002-07-09 19:50 ` Richard B. Johnson
2002-07-10 6:33 ` Alex Riesen
2002-07-10 11:20 ` Richard B. Johnson
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=20020715133507.GF32155@merlin.emma.line.org \
--to=matthias.andree@stud.uni-dortmund.de \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®