Arch Linux

phignuton

Member

Registered: 2008-02-07

Posts: 6

/etc/fstab options not working for root filesystem

Recently, I've noticed that my root file system is mounted in a very unsafe
(IMHO) manner. Observe:

mount | grep sda3
/dev/sda3 on / type ext3 (rw,relatime,errors=continue,acl,barrier=0,data=writeback)

What this means to me, is that my root fs is mounted for high-performance at
the expense of data integrity in the event of a power failure. Frankly, that
happens all too often in my neighborhood (don't ask) and I've been dealing with
some pretty heavy corruption on my drive.

This only affects /. /home is also ext3, however that mount respects the
settings in /etc/fstab.

What's very odd and quite vexing about this though is that the options specified
in my fstab entry for that fs are as such:

LABEL=64Root / ext3 acl,defaults 0 1
LABEL=64Home /home ext3 nodiratime,data=journal,defaults 0 1

In no file in /etc/ does it say anything about disabling barriers or changing the data
journal to writeback. In fact, I can't find mention of this setting in any config
file in /etc/ at all.

[root@omega ~]# grep -Ril writeback /etc/*
/etc/mtab
[root@omega ~]#

During "normal" startup, the following messages are shown when / is mounted:

 
EXT3-fs (sda3): using internal journal
EXT3-fs: barriers not enabled
kjournald starting.  Commit interval 5 seconds

However, when /home is mounted, these messages are shown:

EXT3-fs (sda4): using internal journal
EXT3-fs (sda4): mounted filesystem with journal data mode
EXT3-fs: barriers not enabled

Any attempt to override the barrier and data settings for / result in a error
on reboot. At that point the root filesystem will not mount and I end up in
single-user mode hell.

I've tried changing the fstab entry to both this:

LABEL=64Root / ext3 acl,barrier=1,data=journal,defaults 0 1

and this:

/dev/disk/by-uuid/ac62b19e-d5be-429a-92ff-3749a4dffac4 / ext3 acl,barrier=1,data=journal,defaults 0 1

in a clutch attempt to fix this. Both entries result in the same problem.

I have an Arch32 installation on this machine, booting from a separate drive,
and it doesn't exhibit the same behavior. Personally, I'm out of ideas. Do any
of you fine folks have an idea of how to proceed?

And let me add, this may have been the case for quite some time on this machine.
I'm guilty of falling into the "it just works" camp and never noticed a problem until the
random drive corruption.