From: Matthias Andree <matthias.andree@gmx.de>
To: Jens Axboe <axboe@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, matthias.andree@gmx.de
Subject: Re: True fsync() in Linux (on IDE)
Date: Thu, 18 Mar 2004 13:21:45 +0100 [thread overview]
Message-ID: <20040318122145.GA9175@merlin.emma.line.org> (raw)
In-Reply-To: <20040318115544.GN22234@suse.de>
Jens Axboe schrieb am 2004-03-18:
> > All these ATA fsync() vs. write cache issues have been open for much too
> > long - no reproaches, but it's a pity we haven't been able to have data
> > consistency for data bases and fast bulk writes (that need the write
> > cache without TCQ) in the same drive for so long. I have seen Linux
> > introduce TCQ for PATA early in 2.5, then drop it again. Similarly,
> > FreeBSD ventured into TCQ for ATA but appears to have dropped it again
> > as well.
>
> That's because PATA TCQ sucks :-)
True. Few drives support it, and many of these you would not want to run
in production...
> > May I ask that the information whether a particular driver (file system,
> > hardware) supports write barriers be exposed in a standard way, for
> > instance in the Kconfig help lines?
>
> Since reiser is the first implementation of it, it gets to chose how
> this works. Currently that's done by giving -o barrier=flush (=ordered
> used to exist as well, it will probably return - right now we just
> played with IDE).
This looks as though this was not the default and required the user to
know what he's doing. Would it be possible to choose a sane default
(like flush for ATA or ordered for SCSI when the underlying driver
supports ordered tags) and leave the user just the chance to override
this?
> Only PATA core needs to support it, not the chipset drivers. md and dm
Hum, I know the older Promise chips were blacklisted for PATA TCQ in
FreeBSD. Might "ordered" cause situations where similar things happen to
Linux? How about SCSI/libata? Is the situation the same there?
> aren't a difficult to implement now that unplug/congestion already
> iterates the device list and I added a blkdev_issue_flush() command.
So this would - for SCSI - be an sd issue rather than a driver issue as
well?
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
next prev parent reply other threads:[~2004-03-18 12:21 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-18 1:08 True fsync() in Linux (on IDE) Peter Zaitsev
2004-03-18 6:47 ` Jens Axboe
2004-03-18 11:34 ` Matthias Andree
2004-03-18 11:55 ` Jens Axboe
2004-03-18 12:21 ` Matthias Andree [this message]
2004-03-18 12:37 ` Jens Axboe
2004-03-18 11:58 ` (no subject) Daniel Czarnecki
2004-03-18 19:44 ` True fsync() in Linux (on IDE) Peter Zaitsev
2004-03-18 19:47 ` Jens Axboe
2004-03-18 20:11 ` Chris Mason
2004-03-18 20:17 ` Peter Zaitsev
2004-03-18 20:33 ` Chris Mason
2004-03-18 20:46 ` Peter Zaitsev
2004-03-18 21:02 ` Chris Mason
2004-03-18 21:09 ` Peter Zaitsev
2004-03-18 21:19 ` Chris Mason
2004-03-19 8:05 ` Hans Reiser
2004-03-19 13:52 ` Chris Mason
2004-03-19 19:26 ` Peter Zaitsev
2004-03-19 20:23 ` Chris Mason
2004-03-19 20:31 ` Hans Reiser
2004-03-19 20:38 ` Chris Mason
2004-03-19 20:48 ` Hans Reiser
2004-03-19 20:56 ` Chris Mason
2004-03-20 11:04 ` Hans Reiser
2004-03-19 19:36 ` Hans Reiser
2004-03-19 19:57 ` Chris Mason
2004-03-19 20:04 ` Hans Reiser
2004-03-19 20:15 ` Chris Mason
2004-03-19 20:06 ` Peter Zaitsev
2004-03-19 22:03 ` Matthias Andree
2004-03-20 10:20 ` Jamie Lokier
2004-03-20 19:48 ` Peter Zaitsev
2004-03-22 13:08 Heikki Tuuri
2004-03-22 13:23 ` Jens Axboe
2004-03-22 15:17 ` Matthias Andree
2004-03-22 15:35 ` Christoph Hellwig
2004-03-22 19:12 ` Christoffer Hall-Frederiksen
2004-03-22 20:28 ` Matthias Andree
2004-03-22 19:33 ` Hans Reiser
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=20040318122145.GA9175@merlin.emma.line.org \
--to=matthias.andree@gmx.de \
--cc=axboe@suse.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;
as well as URLs for NNTP newsgroup(s).