All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	chris.mason@oracle.com, tytso@mit.edu, adilger@sun.com,
	swhiteho@redhat.com, konishi.ryusuke@lab.ntt.co.jp,
	mfasheh@suse.com, joel.becker@oracle.com
Subject: Re: notes on volatile write caches vs fdatasync
Date: Thu, 27 Aug 2009 15:26:24 -0400	[thread overview]
Message-ID: <4A96DDE0.9090306@garzik.org> (raw)
In-Reply-To: <20090827184948.GA1367@lst.de>

On 08/27/2009 02:49 PM, Christoph Hellwig wrote:
> On Thu, Aug 27, 2009 at 03:02:52PM +0200, Jan Kara wrote:
>>    I've noticed this as well when we were tracking some problems Pavel
>> Machek found with his USB stick. I even wrote a patch at the time
>>    http://osdir.com/ml/linux-ext4/2009-01/msg00015.html
>> but it somehow died out. Now, the situation should be simpler with
>> fsync paths cleaned up... BTW: People wanted this to be configurable per
>> block device which probably makes sence...
>
> Yeah, that patch is pretty ugly.  We need to do these cache flushes
> in ->fsync (and ->sync_fs if any filesystem really doesn't guarantee to
> issue  transaction there after data has been written).  Adding it
> to simple_fsync too sounds good to me.

Agreed.  That was the direction I was heading with my patch[1].  Last 
feedback I got on that was needing to add a knob to optionally disable 
this new cache-flush behavior.

	Jeff



[1] http://lkml.org/lkml/2009/3/27/366

      reply	other threads:[~2009-08-27 19:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-27  1:16 [PATCH] notes on volatile write caches vs fdatasync Christoph Hellwig
2009-08-27  1:19 ` Christoph Hellwig
2009-08-27 13:02 ` Jan Kara
2009-08-27 18:49   ` Christoph Hellwig
2009-08-27 19:26     ` Jeff Garzik [this message]

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=4A96DDE0.9090306@garzik.org \
    --to=jeff@garzik.org \
    --cc=adilger@sun.com \
    --cc=chris.mason@oracle.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=joel.becker@oracle.com \
    --cc=konishi.ryusuke@lab.ntt.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfasheh@suse.com \
    --cc=swhiteho@redhat.com \
    --cc=tytso@mit.edu \
    /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.