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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:30 EST