All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
	"Huang Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"Juergens Dirk (CM-AI/ECO2)" <Dirk.Juergens@de.bosch.com>
Subject: Re: ext4 filesystem bad extent error review
Date: Fri, 03 Jan 2014 11:23:54 -0600	[thread overview]
Message-ID: <52C6F22A.4040202@redhat.com> (raw)
In-Reply-To: <20140103154846.GB31411@thunk.org>

On 1/3/14, 9:48 AM, Theodore Ts'o wrote:
> On Fri, Jan 03, 2014 at 11:16:02AM +0800, Huang Weller (CM/ESW12-CN) wrote:
>>
>> It sounds like the barrier test. We wrote such kind test tool
>> before, the test program used ioctl(fd, BLKFLSBUF, 0) to set a
>> barrier before next write operation.  Do you think this ioctl is
>> enough ? Because I saw the ext4 use it. I will do the test with that
>> tool and then let you know the result.
> 
> The BLKFLSBUF ioctl does __not__ send a CACHE FLUSH command to the
> hardware device.  It forces all of the dirty buffers in memory to the
> storage device, and then it invalidates all the buffer cache, but it
> does not send a CACHE FLUSH command to the hardware.  Hence, the
> hardware is free to write it to its on-disk cache, and not necessarily
> guarantee that the data is written to stable store.  (For an example
> use case of BLKFLSBUF, we use it in e2fsck to drop the buffer cache
> for benchmarking purposes.)

Are you sure?  for a bdev w/ ext4 on it:

BLKFLSBUF
	fsync_bdev
		sync_filesystem
			sync_fs
				ext4_sync_fs
					blkdev_issue_flush


-Eric


  parent reply	other threads:[~2014-01-03 17:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-02  4:59 ext4 filesystem bad extent error review Huang Weller (CM/ESW12-CN)
2014-01-02 18:42 ` Theodore Ts'o
2014-01-03  3:16   ` Huang Weller (CM/ESW12-CN)
2014-01-03 15:48     ` Theodore Ts'o
2014-01-03 16:40       ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-06  2:23         ` Huang Weller (CM/ESW12-CN)
2014-01-03 17:23       ` Eric Sandeen [this message]
2014-01-03 17:51         ` Theodore Ts'o
2014-01-03 17:54           ` Eric Sandeen
2014-01-03 18:06             ` Theodore Ts'o
2014-01-03 18:21               ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-06  3:53                 ` Huang Weller (CM/ESW12-CN)
2014-01-03 16:29   ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-03 17:25     ` Eric Sandeen
2014-01-03 18:45       ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-03 18:48         ` Eric Sandeen
2014-01-03 18:56           ` AW: " Juergens Dirk (CM-AI/ECO2)
2014-01-06  5:45             ` Huang Weller (CM/ESW12-CN)
2014-01-06  1:44           ` Huang Weller (CM/ESW12-CN)
2014-01-06  5:17         ` Huang Weller (CM/ESW12-CN)
2014-01-06  5:10       ` [Attachment has been removed]RE: " Huang Weller (CM/ESW12-CN)
2014-01-07  9:10       ` Huang Weller (CM/ESW12-CN)

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=52C6F22A.4040202@redhat.com \
    --to=sandeen@redhat.com \
    --cc=Dirk.Juergens@de.bosch.com \
    --cc=Weller.Huang@cn.bosch.com \
    --cc=linux-ext4@vger.kernel.org \
    --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.