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>
1 file changed
