tree 9eaaf0bcda19d3287e01159062c6e2f7fe5b4137
parent 2715fc65bb6fdcff7c797b74252ae8f69da60863
author Jaegeuk Kim <jaegeuk@google.com> 1527536688 -0700
committer Jaegeuk Kim <jaegeuk@google.com> 1527789741 -0700

fstab: use fsync_mode=nobarrier

This patch proposes to skip FLUSH commands for UFS when fsync(2) for non-atomic
files is called.

== Pros ==
 - huge gain on random write/fsync test from 30MB/s to 90MB/s
   (e.g., Androbench)
 - extented flash lifetime
   (FLUSH command requires for FTL to write its metadata)

== Cons ==
In terms of stability,
1) checkpoint issues FLUSH, so this doesn't hurt F2FS consistency.
2) atomic write issues FLUSH, so SQLite w/ journal mode would be safe.
3) non-atomic fsync() doesn't issue FLUSH, so there is one scenario to consider
where:
   a. fsync() flushes data blocks to disk, and then node blocks. The last node
      block contains a flag as the candidate for roll-forward recovery.
   b. assuming that storage is able to flush disk cache in out-of-order manner,
      all the cached node blocks are written to the flash cell, followed by all
      the data blocks.
   c. cut power
   d. F2FS conducts roll-back to the last checkpoint w/o risk. Then, it starts
      roll-forward recovery which traverses the node block chain and finds node
      blocks written by b. lastly.
   e. After mount, user can see old or zero data from the recovered node blocks.

Three points persuaded me to go with this:
1) In the above scenario, it won't hurt filesystem consistency.
2) Generally, firmware in embedded UFS/eMMC doesn't do out-of-order writes,
   since it doesn't have large cache to reorder write IOs likewise SSDs.
3) It'd be okay to lose the last-called fsync() due to power-cut, since users
   won't be aware of it mostly.

Bug: 34123235
Change-Id: Ieb163de5136a621d379dd5bcd762b4307b8dd46f
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>