Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
Provides some guidance around data=journal. I'd be inclined to use that over anything else since RH only supports that type of ordering. –  slm Jun 10 '13 at 12:15
2  
@sim actually it says data=ordered :p –  sourcejedi Jun 12 '13 at 19:40

3 Answers 3

up vote 6 down vote accepted
+50

Don't get misled by the fact that only writeback mentions internal filesystem integrity.
In 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.
So, if data integrity is your main concern and speed is not important, data=journal is the way to go.

share|improve this answer

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.

share|improve this answer

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".

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.