[Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming

[Theodore Ts'o]

The blog post here:
https://raid6.com.au/posts/fs_ext4_external_journal_caveats/

is not generally true.   What journal_async_commit does is convert the
sequence:

1.  write journal blocks
2.  cache flush
3.  write journal commit block
4.  cache flush

... to:

1.  write journal blocks
2.  write journal commit block
3.  cache flush

This tends to make a lot of difference on HDD's from a performance
perspective, because a cache flush commands are so expensive.   On an
SSD with a competently implemented flash translation layer (FTL), it
shouldn't make much of a difference from a performance perspective, and
it shouldn't hardly any difference from write endurance perspective.

The way flash works is that flash chips are organized into erase blocks,
which might be say, 64k.   This is the minimal size must be erased as a
unit.  Once an erase block is cleared (which is the slow operation) it
can be written a flash page (typically 4k in size) at a time.  Once a
flash page is written, it can't be erased except by erasing the entire
erase block.   If most of the erase blocks are filled, either with real
data, or with garbage (former data contents which have been superceded),
then it might be necessary to copy the still-used data contents to other
erase blocks, so that an erase block can be emptied so it can be erased.
If it is necessary to do those extra copies before the erase block can
be rebase, this is cause of the "write amplifification" effect.

However, doing an extra CACHE FLUSH operation (which is what
journal_async_commit eliminates) should not make any difference on any
competently implemented FTL on a normal SSD.

The place where it make a difference is on what gets referred to as
"cost optimized" flash in polite company, or "crap flash" by more honest
engineers.  You will most often find this in eMMC flash or SD cards
found in the cash register aisle of Micro Center (assuming of course,
that you actually get honestly labelled flash as opposed to a SD card
claiming to have 1G of flash, but which is only backed by 16 MB of flash
--- such that the 16MB + 4k write will end up overwriting previously
written data).    In these "cost optimized" flash, the FTL may end up
mapping each 64k erase page to a 64k LBA address space.  In that case, a
4k write followed by a cache flush will end up being the equivalent of a
64k flash erase/write.  In the even more awful "crappy flash", each 64k
erase block is direct mapped to a 64k LBA address space.  In that case,
if you are constantly overwriting any portion of the flash (either the
FAT table for FAT file systems, or the journal in ext4), then those
erase blocks will get worn out first --- and once they are worn out, the
flash device becomes broken.

But I emphasize that this is really only a problem for crap flash.  For
a normal SSD with a competent FTL, the use of journal_async_commit (or
not using journal_async_commit) should not make any real difference to
how long your flash device lasts.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1365874

Title:
  Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata
  checksumming

Status in e2fsprogs package in Ubuntu:
  Triaged

Bug description:
  In the Trusty release notes "Metadata checksumming" is listed as one
  of the tech highlights of kernel 3.13.

  https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS

  However, the userland tools do not support this kernel feature. To the
  best of my knowledge this will be supported in 1.43, and won't be
  backported to 1.42.

  IMHO this is very misleading. It's like a car salesperson sold you a
  sports car with an V8 engine. After you drove it home, you opened the
  hood and realized only 6 cylinders are working because 2 of the spark
  plugs were not included, and you have to buy aftermarket ones.

  <rant>BTW, I've been following the development of e2fsprogs for over a
  year. 1.43  release has been in limbo for God knows how long :(
  </rant>

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions