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

Re: [Xen-users] repeated DomU volume corruption



I was experiencing similar issue on CPU and IO bound domU and barrier=0/nobarrier helped me.
Check whether the barriers were disabled (dmesg| awk '/xvda/||/barrier/').
Check whether some IO errors are visible on Dom0 as it provides the storage layers.

--
Peter Viskup

On Sat, Dec 6, 2014 at 1:27 PM, Robert Rust <rjrbytes@xxxxxxxxx> wrote:
I'm not sure there's been a significant improvement. I just did package updates and 4 of my 7 VMs ended up exhibiting this problem. One may have already been in that state when I started (hard to tell), a second appeared to have it happen mid-shutdown, a third had it happen after it completed downloading the package updates but hadn't installed them yet, and the 4th I'm not certain of. All 4 had the nobarrier option in their fstab:
/dev/xvda2 / ext4 nobarrier,noatime,nodiratime,errors=remount-ro 0 1

Further thoughts?

-Robert

On Mon, Nov 24, 2014 at 8:29 PM, Robert Rust <rjrbytes@xxxxxxxxx> wrote:
On Mon, Nov 24, 2014 at 1:10 PM, Steve Dawson <sdawson@xxxxxxxxxxxxxxxx> wrote:
I had an issue similar in nature, which manifested as a missing partition table after a domU reboot, mounting the xvda{x} partitions with the "nobarrier" mount option resolved it. The issue was observed on xfs and ext4 filesystems.

Hope this helps.

Steve

Okay. I've added the nobarrier option to all my DomUs ... we'll see how that goes. Here's hoping it's that simple ...

-Robert



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

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