All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@innominate.de>
To: "Stephen C. Tweedie" <sct@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: sync & asyck i/o
Date: Tue, 06 Feb 2001 19:21:00 +0100	[thread overview]
Message-ID: <3A80408C.E854B37A@innominate.de> (raw)
In-Reply-To: <200102061424.PAA32284@hell.wii.ericsson.net> <E14Q9U2-0005gX-00@the-village.bc.nu> <20010206173437.A19836@redhat.com>

"Stephen C. Tweedie" wrote:
> 
> Hi,
> 
> On Tue, Feb 06, 2001 at 02:52:40PM +0000, Alan Cox wrote:
> > > According to the man page for fsync it copies in-core data to disk
> > > prior to its return. Does that take async i/o to the media in account?
> > > I.e. does it wait for completion of the async i/o to the disk?
> >
> > Undefined.
> 
> > In practice some IDE disks do write merging and small amounts of write
> > caching in the drive firmware so you cannot trust it 100%.
> 
> It's worth noting that it *is* defined unambiguously in the standards:
> fsync waits until all the data is hard on disk.  Linux will obey that
> if it possibly can: only in cases where the hardware is actively lying
> about when the data has hit disk will the guarantee break down.

Sometimes I want to know that the write is safely on disk and sometimes
I only need to know that the io has gone over the bus and is on its way
to disk.  In the latter case the buffer/page can be unlocked a lot
sooner.  Please correct me if I'm wrong, but I don't think the current
API can make that distinction for IDE, much less provide a uniform way
of controlling this behaviour across all types of block devices.  We
need that, or else we have to choose between the following: 1) slow 2)
risky.

I'd like to be able to set a bit in the buffer_head that says 'get back
to me when it's on disk' vs 'get back to me when it's hit the bus'.
	
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2001-02-06 18:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-06 14:24 sync & asyck i/o Anders Eriksson
2001-02-06 14:52 ` Alan Cox
2001-02-06 17:34   ` Stephen C. Tweedie
2001-02-06 18:00     ` Ben LaHaise
2001-02-06 18:21     ` Daniel Phillips [this message]
2001-02-06 17:51   ` Josh Myer
2001-02-06 17:56     ` Alan Cox
2001-02-06 17:54   ` David Woodhouse
2001-02-06 18:18     ` Stephen C. Tweedie
2001-02-06 19:25       ` Andre Hedrick
2001-02-06 23:21         ` Stephen C. Tweedie
2001-02-07  0:42           ` Andre Hedrick

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=3A80408C.E854B37A@innominate.de \
    --to=phillips@innominate.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sct@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.