Root Filesystem Mounts Readonly After Update

[lesbell]

After this morning's (Australia time) update (was this the 7.4 upgrade) my web server (running on Google Compute Engine) failed to restart. A little probing around revealed that the root filesystem was now mounted readonly, so that a bunch of services were unable to run. To cut a long story short, dmesg ended with the line:

Code: Select all

XFS (sda1): unknown mount option [barrier=0]

and I discovered that /etc/fstab had the line

Code: Select all

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xfs     defaults,barrier=0 1 1

To remount the root filesystem, I used the command

Code: Select all

mount -n -o remount,defaults /dev/sda1 /

and then edited /etc/fstab to remove the ",barrier=0" option. After a reboot, the server seems to be running just fine.

I'm posting this a) to help anyone else who runs into the same problem and b) to ask about this "barrier=0" option and why it suddenly caused the problem. I can see that xfsprogs was updated as part of this upgrade, but I don't know if "barrier=0" was there before this, or what the implications of removing it are (I know very little about xfs).

Is anybody else seeing similar problems, and is there a better fix?

Best,

--- Les

[lesbell]

OK, I think I've sorted this out. Although at some time, the mount option "barrier=0" to disable write barriers might have been correct, it appears the correct mount option these days is "nobarrier". See, e.g. the XFS FAQ section on write barriers at http://xfs.org/index.php/XFS_FAQ#Write_barrier_support.

So, if anyone else strikes this problem, remount the root filesystem rw to make it possible to edit /etc/fstab, and then change the mount option from "barrier=0" to "nobarrier" and you should be back in business.

Disabling write barriers will increase performance on drive controllers which are battery-backed or otherwise will not lose data on power failure - which I presume Google's Compute Engine cloud NAS effectively is.

Best,

--- Les

[hunter86_bg]

Removing the write barriers leads to ~2-3% performance increase but in some cased would cause complete destruction of the File system (for example - when no battery-backed disk cache is available).

[lesbell]

Removing the write barriers leads to ~2-3% performance increase but in some cased would cause complete destruction of the File system (for example - when no battery-backed disk cache is available).

I'm guessing that the "barrier=0" option is specific to the Google Compute Engine CentOS 7 image, where the "drives" are allocated from a SAN, and there's no local disk controllers. It certainly isn't there on my own local CentOS 7 installs. So the problem may well be specific to Google.

Best,

--- Les

[lesbell]

So the problem may well be specific to Google.

A final (I hope) update on this. I raised an issue with Google on, at https://issuetracker.google.com/issues/65658554. They confirm the latest GCE image does not have write barriers disabled and so is unaffected, but the problem does appear with instances based on the centos-7-v20160301 image, while my own instance was based on centos-7-v20150603. So, for anyone planning to spin up a CentOS image on Google Compute Engine, this will not be a problem - it will only emerge on updates on older instances.

--- Les