public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: mike.miller@hp.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-scsi@vger.kernel.org, brace@hp.com
Subject: Re: [Question] Does the kernel ignore errors writng to disk?
Date: Fri, 29 Apr 2005 01:22:34 +0200	[thread overview]
Message-ID: <58cb370e050428162221be7338@mail.gmail.com> (raw)
In-Reply-To: <1114700283.24687.193.camel@localhost.localdomain>

On 4/28/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Mer, 2005-04-27 at 19:40, mike.miller@hp.com wrote:
> > It looks like the OS/filesystem (ext2/3 and reiserfs) does not wait for for a successful completion. Is this assumption correct?
> 
> Of course it doesn't. At 250 ops/second for a decent disk no OS waits
> for completions, all batch and asynchronously queue I/O. See man fsync
> and also O_DIRECT if you need specific "to disk" support. If you do that
> be aware that you must also turn write caching off on the IDE disk. I've
> repeatedly asked the "maintainer" of the IDE layer to do this
> automatically but gave up bothering long ago. Without that setting users

WTF is wrong with you Alan?

We agreed on this but it is you to do coding, if you want it,
not me (and there was never any patch from you).

It is not my (unpaid) job to fulfill any requirement you come up with.

BTW I was supposed to push git update today but I wasted this time 
on replying your complaints (didn't even bother with personal insults). 

> are playing with fire quite honestly.
> 
> The alternative with latest 2.6 stuff is to turn on Jens Axboe's barrier
> work which seems to give better performance on a drive new enough to
> have cache flush operations.

  parent reply	other threads:[~2005-04-28 23:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-27 18:40 [Question] Does the kernel ignore errors writng to disk? mike.miller
2005-04-27 19:12 ` Richard B. Johnson
2005-04-28 14:58 ` Alan Cox
2005-04-28 18:14   ` Bryan Henderson
2005-04-28 22:43     ` Alan Cox
2005-04-28 23:14       ` Bryan Henderson
2005-04-29  7:25         ` Anton Altaparmakov
2005-04-29 19:11           ` Bryan Henderson
2005-04-29 22:00             ` Alan Cox
2005-04-30  0:41               ` Bryan Henderson
2005-05-01  9:01               ` Mogens Valentin
2005-04-28 23:22   ` Bartlomiej Zolnierkiewicz [this message]
2005-04-28 23:50     ` Alan Cox
2005-04-29  0:33       ` Bartlomiej Zolnierkiewicz
  -- strict thread matches above, loose matches on Subject: below --
2005-04-28 15:05 Miller, Mike (OS Dev)

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=58cb370e050428162221be7338@mail.gmail.com \
    --to=bzolnier@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=brace@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mike.miller@hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox