15

I have an embedded setup using an initramfs for the root file system but using a custom ext3 partition mounted on a compact flash IDE drive. Because data integrity in the face of power loss is the most important factor in the entire setup, I have used the following options to mount (below is the entry from my /etc/fstab file

<file system> <mount pt> <type> <options>                         <dump><pass>
/dev/sda2     /data      ext3   auto,exec,relatime,sync,barrier=1 0     2

I came by these options from reading around on the internet. What I am worried about is that the content of /proc/mounts give the following:

/dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl,
barrier=1,data=writeback 0 0

From what I understand from reading around is that I want to use data=journal option for my mount as this offers the best protection against data corruption. However, from the man page for specific ext3 options for mount it says the following about the writeback option:

Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal.
This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.

I am very confused about this - the man page seems to suggest that for file system integrity I want to specify data=writeback option to mount but most other references I have found (including some published books on embedded linux) suggest that I should be using data=journal. What would be the best approach for me to use? Write speed is not an issue at all - data integrity is though.

mathematician1975
  • 1,473

3 Answers3

7

Don't get misled by the fact that only writeback mentions internal filesystem integrity.
With ext3, whether you use journal, ordered or writeback, file system metadata is always journalled and that means internal file system integrity.

The data modes offer a way of control over how ordinary data is written to the file system.
In writeback mode, metadata changes are first recorded in the journal and a commit block is written. After the journal has been updated, metadata and data write-outs may proceed. data=writeback can be a severe security risk: if the system crashes while appending to a file, after the metadata has been committed (and additional data blocks allocated), but before the data has been written (data blocks overwritten with new data), then after journal recovery that file may contain blocks filled with data from previously deleted files – from any user1.

So, if data integrity is your main concern and speed is not important, data=journal is the way to go.

don_crissti
  • 82,805
5

As you have already noticed, main point is that you cannot prevent your filesystem from all kind of crash.

What you can do:

  1. On software side, you can use fdatawrites after each important operation (See this 2003 post from Theodore T'so, a main Linux FS Kernel developer. it's still true. There's also this one about a major data loss hidden in older versions of ext4)
  2. Reduce commit interval to 1 second (commit=1) (see this article from LWN, it's about ext4 but contains really usefull informations about ext3). NB: It shouldn't be needed, with sync.
  3. As RHEL doc pointed by sim said, use *data_err=abort* and data=ordered
  4. noatime will reduce useless operations on filesystem
  5. As you have already noticed, barrier=1 is a good way to minimize data loss (see this post)
  6. And sync is also, of course, one of the "I don't want to lose my data" option.

At the end, paranoiac mount options can look like this:

auto,exec,relatime,sync,barrier=1,commit=1,data=ordered,data_err=abort,noatime,

And you can also ensure data integrity with an automatic fsck at each boot.

Coren
  • 5,010
2

Try changing which part of the man page you empahsize:

writeback

Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.

As don_crissti pointed out, the other modes don't have the "however".

depquid
  • 3,891