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

Re: [Xen-users] fsck -n, xen hpervisors 3.2.1 and 3.0.3



Hi Joseph,

George Shuklin suggested "I do remember some problems with newer barrier system in ext filesystem in 3.x kernels. Try to add 'nobarrier' as mount option for all filesystem in guest VM.".  I haven't done this yet because I wanted to check in to that if the domU is shut down suddenly there is a higher risk of corruption.  The docs relating to barrier talk about an old version of XFS that doesn't support it; I'm running plain old ext3.  Nothing about barriers appear in any log or dmesg.

Normally I can google for such a common problem and get matches.  The same behavior is occurring on two different physical machines running etch so it is unlikely to be unique to our systems.  But nobody else has had the problem?  That strikes me as very odd.  There was one guy that had a very large thread about fscking an image that wouldn't boot due to errors, but that didn't seem to be quite the same thing and I couldn't find any interesting solutions.

What sparked this is that I have taken over a role in which some legacy production systems have been configured as domUs in this fashion.  These machines are never taken down, so they never get disk checks.  So here's me thinking "fsck -n /dev/sda1" as a cron job will be a good idea; just to let us know if a problem is headed our way.  Another tech has suggested that maybe this output is erroneous but I'm extremely uneasy about that.

I'll keep investigating a solution - I just thought to query you guys if you remember anything like this because it's difficult to believe I'm the only one that's experienced it!


Cheers guys :)
Marc

On 11/11/2011 12:44 AM, Joseph Glanville wrote:
Hi Marc,

Does the message "write barriers disabled" appear in dmesg or syslog on boot?

Joseph.

On 7 November 2011 21:43, Marc Lucke <marc@xxxxxxxxxxxxxxxx> wrote:
Hi list,

I'm a noob working with old environments that I can't update (hopefully yet).  On two 32-bit debian systems - both on etch - `fsck -n /dev/sda1` inside each domU finds errors even after a fsck fix on reboot reports clean.

Storage are img files.  Again I want to take them to lvms, but not an option atm.

I've seen some threads close to this and it seems like it's the fsck that's faulty?

Can anyone enlighten me?


Cheers
Marc

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



--
Founder | Director | VP Research
Orion Virtualisation Solutions
 | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
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®.