[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [patch] Add support for barriers to blk{back, front} drivers.

  • To: "Gerd Hoffmann" <kraxel@xxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Fri, 27 Oct 2006 14:46:08 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 27 Oct 2006 06:47:08 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acb4VgrG3Er3F5NZTDeSP0NZJ+LsVgBcmLDg
  • Thread-topic: [Xen-devel] [patch] Add support for barriers to blk{back, front} drivers.

> With write caching disabled barriers don't make a big 
> difference, it's in the noise.  Not surprising.  With write 
> caching enabled barriers make things a bit slower.  But keep 
> in mind that journaling filesystems can NOT work reliable 
> without barriers when write caching is enabled.  The small 
> performance penalty simply is the price to have to pay for 
> filesystem integrity.  The other way to make sure the 
> journaling works ok is to disable write caching.  As you can 
> see this costs even more performance.

What's the current logic for determining whether the backend advertises
barrier support, and whether the frontend chooses to use it?

I guess the backend could always advertise it providing it did the
appropriate queue drain whenever it encoutered one if the underlying
block device didn't support barriers.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.