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

Re: [Xen-users] blkfront: barrier: empty write op failed


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Luca Lesinigo <luca@xxxxxxxxx>
  • Date: Thu, 1 Dec 2011 10:28:00 +0100
  • Delivery-date: Thu, 01 Dec 2011 09:30:00 +0000
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

After upgrading domU from linux-3.0.4 to 3.0.11I still get these nasty messages 
from dmesg when mounting the EXT3 filesystem during boot:
        blkfront: barrier: empty write xvda1 op failed
        blkfront: xvda1: barrier or flush: disabled
        EXT3-fs (xvda1): using internal journal

this 64bit domU is running under Xen-4.1.1 with a 2.6.38 kernel (gentoo's 
xen-sources which basically is a backport of XenLinux patches).

The system appears to keep working correctly anyway but I suspect it slows down 
a little too much under heavy I/O (for example, copying many gigabytes from an 
ext3 to another).

Working with raw blocks (eg. swap volumes, or running dd over a not-mounted 
ext3 volume) does not trigger that message, running a single mkfs.ext3 or 
mkfs.ext4 does make it appear. I usually have cleancache enabled over tmem, 
disabling it doesn't seem to make any difference.

Ubuntu domUs using their stock 2.6.24-??-xen kernel seem to be immune.

Is this something I should be worried about? What would you suggest to try to 
correct it? (eg. is it something related to domU kernel, dom0 kernel, 
hypervisor, domU config, whatever?)


thanks.

--
Luca Lesinigo
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

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