public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Journaling pointless with today's hard disks?
Date: 26 Nov 2001 16:24:00 -0800	[thread overview]
Message-ID: <9tumf0$dvr$1@cesium.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10111261229190.8817-100000@master.linux-ide.org> <0111261535070J.02001@localhost.localdomain> <20011126165920.N730@lynx.no>

Followup to:  <20011126165920.N730@lynx.no>
By author:    Andreas Dilger <adilger@turbolabs.com>
In newsgroup: linux.dev.kernel
> 
> The other thing that concerns a journaling fs is write ordering.  If you
> can _guarantee_ that an entire track (or whatever) can be written to disk
> in _all_ cases, then it is OK to reorder write requests within that track
> AS LONG AS YOU DON'T REORDER WRITES WHERE YOU SKIP BLOCKS THAT ARE NOT
> GUARANTEED TO COMPLETE.
> 
> Generally, in Linux, ext3 will wait on all of the journal transaction
> blocks to be written before it writes a commit record, which is its way
> of guaranteeing that everything before the commit is valid.  If you start
> write cacheing the transaction blocks, return, and then write the commit
> record to disk before the other transaction blocks are written, this is
> SEVERELY BROKEN.  If it was guaranteed that the commit record would hit
> the platters at the same time as the other journal transaction blocks,
> that would be the minimum acceptable behaviour.
> 
> Obviously a working TCQ or write barrier would also allow you to optimize
> all writes before the commit block is written, but that should be an
> _enhancement_ above the basic write operations, only available if you
> start using this feature.
> 

Indeed; having explicit write barriers would be a very useful feature,
but the drives MUST default to strict ordering unless reordering (with
write barriers) have been enabled explicitly by the OS.

Furthermore, I would like to add the following constraint to your
writeup:

** For each individual sector, a write MUST either complete or not
   take place at all.  In other words, writes are guaranteed to be
   atomic on a sector-by-sector basis.

	-hpa


P.S. Thanks, Andre, for taking the initiative of getting an actual
commit model into the standardized specification.  Otherwise we'd be
doomed to continue down the path where what operating systems need for
sane operation and what disk drives provide are increasingly
divergent.
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

  reply	other threads:[~2001-11-27  0:24 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-24 13:03 Journaling pointless with today's hard disks? Florian Weimer
2001-11-24 13:40 ` Rik van Riel
2001-11-24 16:36   ` Phil Howard
2001-11-24 17:19     ` Charles Marslett
2001-11-24 17:31     ` Florian Weimer
2001-11-24 17:41     ` Matthias Andree
2001-11-24 19:20       ` Florian Weimer
2001-11-24 19:29         ` Rik van Riel
2001-11-24 22:51           ` John Alvord
2001-11-24 23:41             ` Phil Howard
2001-11-25  0:24               ` Ian Stirling
2001-11-25  0:53                 ` Phil Howard
2001-11-25  1:25                   ` H. Peter Anvin
2001-11-25  1:44                   ` Sven.Riedel
2001-11-24 22:28         ` H. Peter Anvin
2001-11-25  4:49           ` Andre Hedrick
2001-11-24 23:04         ` Pedro M. Rodrigues
2001-11-24 23:23         ` Stephen Satchell
2001-11-24 23:29           ` H. Peter Anvin
2001-11-26 18:05             ` Steve Brueggeman
2001-11-26 23:49               ` Martin Eriksson
2001-11-27  0:06                 ` Andreas Dilger
2001-11-27  0:16                   ` Andre Hedrick
2001-11-27  7:38                     ` Andreas Dilger
2001-11-27 11:48                       ` Ville Herva
2001-11-27  0:18                 ` Jonathan Lundell
2001-11-27  1:01                   ` Ian Stirling
2001-11-27  1:33                     ` H. Peter Anvin
2001-11-27  1:57                   ` Steve Underwood
2001-11-27  5:04                   ` Stephen Satchell
     [not found]         ` <mailman.1006644421.6553.linux-kernel2news@redhat.com>
2001-11-25  4:20           ` Pete Zaitcev
2001-11-25 13:52           ` Pedro M. Rodrigues
2001-11-25 12:30         ` Matthias Andree
2001-11-25 15:04           ` Barry K. Nathan
2001-11-25 16:31             ` Matthias Andree
2001-11-27  2:39               ` Pavel Machek
2001-12-03 10:23                 ` Matthias Andree
2001-11-25  9:14 ` Chris Wedgwood
2001-11-25 22:55   ` Daniel Phillips
2001-11-26 16:59   ` Rob Landley
2001-11-26 20:30     ` Andre Hedrick
2001-11-26 20:35       ` Rob Landley
2001-11-26 23:59         ` Andreas Dilger
2001-11-27  0:24           ` H. Peter Anvin [this message]
2001-11-27  0:52             ` H. Peter Anvin
2001-11-27  1:11               ` Andrew Morton
2001-11-27  1:15                 ` H. Peter Anvin
2001-11-27 16:59                   ` Matthias Andree
2001-11-27 16:56               ` Matthias Andree
2001-11-27  1:23         ` Ian Stirling
2001-11-26 23:00           ` Rob Landley
2001-11-27  2:41             ` H. Peter Anvin
2001-11-27  0:19               ` Rob Landley
2001-11-27 23:35                 ` Andreas Bombe
2001-11-28 14:32                   ` Rob Landley
2001-11-27  3:39             ` Ian Stirling
2001-11-27  7:03         ` Ville Herva
2001-11-27 16:50         ` Matthias Andree
2001-11-27 20:31           ` Rob Landley
2001-11-28 18:43             ` Matthias Andree
2001-11-28 18:46               ` Rob Landley
2001-11-28 22:19                 ` Matthias Andree
2001-11-29 22:21                   ` Pavel Machek
2001-12-01 10:55                     ` Jeff V. Merkey
2001-12-02  0:08                     ` Matthias Andree
2001-12-03 20:04                       ` Pavel Machek
2001-11-26 20:53     ` Richard B. Johnson
2001-11-26 21:18       ` Journaling pointless with today's hard disks? [wandering OT] Rob Landley
2001-11-27  0:32       ` Journaling pointless with today's hard disks? H. Peter Anvin
2001-11-27 16:39     ` Matthias Andree
2001-11-27 17:42       ` Martin Eriksson
2001-11-28 16:35         ` Ian Stirling
2001-11-26 17:14 ` Steve Brueggeman
2001-11-26 20:36   ` Andre Hedrick
2001-11-26 21:14     ` Steve Brueggeman
2001-11-26 21:36       ` Andre Hedrick
2001-11-27 16:36         ` Steve Brueggeman
2001-11-27 20:04           ` Bill Davidsen
2001-11-27 21:28         ` Wayne Whitney
2001-11-27 21:52           ` Andre Hedrick
2001-11-28 11:53             ` Pedro M. Rodrigues
  -- strict thread matches above, loose matches on Subject: below --
2001-11-25  1:20 dnu478nt5w@mailexpire.com
2001-11-28 14:36 Galappatti, Kishantha
2001-11-28 17:22 David Balazic
2001-11-28 23:25 Frank de Lange
2001-11-29  1:52 ` Matthias Andree

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='9tumf0$dvr$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --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