> On Fri, 03 Aug 2001, Eric W. Biederman wrote:
>
> > Actually given that this thread keeps coming up, but no one does anything
> > about it. I'm tempted to suggest we remove chatrr +S support from ext2.
> > Then there will be enough pain that someone will fix the MTA instead of
> > moaning that kernel is slow...
>
> They'd just drop Linux from the list of supported OS's, Linux will
> disappoint people who trusted it, nothing is gained. Deliberate breakage
> will not happen, because it would not help anyone except people with
> twisted minds.
There are some other uses for a fully synchronous disk accesses so I'm
not going to run out and do it. The point is that work arounds for
strange programs is not a right, it is a nice optional feature.
> NO-ONE, including you, has come up with SERIOUS objections against a
> dirsync option, except "is it really so much slower than chattr +S? show
> figures" -- ext3 is being tuned to be fast in spite of chattr +S.
Clear objects against dirsync.
- Extra code maintenance, makes the fs less reliable
(A reason for removing even synchrouns fs operations BTW).
- Unnecessary. fsync(dir) works today.
- dirsync is unlikely to be faster than fsync(file); fsync(dir) [not chattr +S]
You really need something that can say remember these 5 syscalls,
and sync the all their changes to disk togeter to really get an
improvement in sync speed.
- I don't see anyone volunteering to write the code.
> Reconsider your position.
Nope. Right now I would rather
a) Patch the mail programs to do the needed fsync(dir)
b) Totally remove synchrous disk updates from my OS, and
make life really painful.
Before adding a dirsync option.
> Stop trolling please.
It wasn't trying to troll, just get this conversation on some productive
grounds. I think supporting the MTA's is good, so long as it is a two
way relationship.
If someone went out and tried using fsync(dir) and then saying it
sucked we could definentily have more peace.
Using dirsync, and chattr +S hide the real problems that need to get
fixed. Getting a good reliable, and high performance way to commit
actions to a filesystem.
We already have one work around on linux that will work reliably. So
now let's see if we can get a functional high performance solution.
And oh btw, new, functional high performance solutions are not
portable because they haven't been implemented in every operating
system. Full understanding of the problem, and the solutions are two
new for the implementations to have gotten around.
Eric
-
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/