mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 17:35:53 +0200	[thread overview]
Message-ID: <20020715153553.GC22828@merlin.emma.line.org> (raw)
In-Reply-To: <20020715112059.A2316@ti20>

On Mon, 15 Jul 2002, Bill Rugolsky Jr. wrote:

> Put dirsync in 2.4? Sure, good idea.  Dangerous without it? To whom?
> 
> Explain how it is dangerous?  The journalling filesystems perform
> directory updates as transactions.  It's dangerous to your MTA
> perhaps.  Andrew Morton has bent over backwards to find and fix bugs in
> the synchronous write logic and to provide what you wanted, i.e.,
> dirsync.  He and Chris Mason fixed performance problems in ext3 and
> Reiserfs.  Reread the thread -- you insisted repeatedly that you just
> wanted dirsync.  Or was that just the opening gambit?

The code is there, for ext3, but not for reiserfs. A year has passed,
but still, dirsync is not the default. This is directed towards the
maintainers of the kernel, not towards Andrew Morton.

> With all due respect to Wieste, that's nonsense: synchronous write
> in syslog or other logging facilities is a *userspace* policy issue.
> Default synchronous directory updates is a *kernel* policy issue.

I'm well aware of this, and that _by_default_ user-space is more
cautious than kernel-space is beyond my horizon, I'm afraid. Of course,
these things are not really related, as syslog and Linux kernel are
separate projects, but still, it looks strange from the outside.

> I don't have dirsync handy at the moment, so I can't test, but
> I have to ask: have you tried the simple (and IMHO devastating) benchmark
> that I posted back on 2001-08-02 comparing Linux to Solaris file creation,
> 
>    http://marc.theaimsgroup.com/?l=linux-kernel&m=99678208121947&w=2
> 
> i.e., copy a file tree (XFree86-4.1, 33027 files) with hard links.

Nope, I prefer not to play disk hogging games on my Solaris boxen, both
of which are in production :-)

> Recall:
> 
> Solaris: 363.46s real    0.84s user   10.13s system
> Ext2:    real    0m3.823s user    0m0.240s sys     0m3.570s
> Ext3:    real    0m5.106s user    0m0.200s sys     0m3.700s
> 
> "dirsync" gives you what you want; please mount /var (or wherever)
> -o dirsync and leave the kernel defaults as they are.

/var and /home, indeed.

So you prefer speed over safety. That's fine. But that's not sane for a
kernel to do. Cheating benchmarks is what others may call it. I just
call it sad.

-- 
Matthias Andree

  reply	other threads:[~2002-07-15 15:33 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
     [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 [this message]
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=20020715153553.GC22828@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®