From quick inspection:

Typical attributes for Android:
user.inode_cache=0sHAEKAAAAAAA=
user.inode_code_cache=0sHQEKAAAAAAA=
user.default
user.AndroidCache="1"

typical Downloads directory xattrs:
user.TrackedDirectoryName="user"
user.GCacheFiles=0sAA==


user.serial="0"


Migration related:
trusted.CrosDirCryptoMigrationMtime
trusted.CrosDirCryptoMigrationAtime

celes and terra are both braswell systems, x86_64, kernel 3.18.

This should be addressed by  issue 719287 

 60.0.3100.0 had  3446 migrations and this is 2 failures (i.e. < 0.1%)

#4 are you sure? celes is 16 GB system, having around 10GB stateful partition, 
with 35% used means it's got 6GB free.

6GB of metadata with 4k blocks means 1.5 million files.

From the two data points, that data storage has around 6GB free space it does not seem like 719287 would address it.
I suspect if I filled the xattr on ecryptfs side, ext4 crypto side would have less space for xattr that it will fail with ENOSPC.

The available space is 4k+96 bytes.

I was suspecting that safe browsing stores source URL and referrer URL on xattr, size of URL can be around 4k. 

https://cs.chromium.org/chromium/src/content/common/quarantine/quarantine_constants_linux.h?q=setxattr+package:%5Echromium$&dr=C&l=18

You're right, that would explain things.  Unfortunately I'm also not sure how we could fix it...
Storing the timestamp xattrs on the source file would only be a marginal change (the source file would likely just run out of space instead of the destination) and even if we don't apply timestamp xattrs at all we may still run out of space with the ext4 encryption xattr.
Increasing inode size would solve the problem, but can't really be done safely on existing systems.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b5cd8f14b7d6df9fd446db36661bfefa19e4e080

commit b5cd8f14b7d6df9fd446db36661bfefa19e4e080
Author: dspaid <dspaid@chromium.org>
Date: Tue Jun 13 02:09:29 2017

Add histograms for enospc cryptomigration errors.

During ecryptfs->ext4-crypto migration we are getting some ENOSPC errors
which are not well understood.  Add UMA metrics to attempt to get a
better understanding as to the cause of these errors.
Metrics reporting added in
https://chromium-review.googlesource.com/c/527742/

BUG= 728970 
TEST=./validate_format.py && ./pretty_print.py

Review-Url: https://codereview.chromium.org/2935633002
Cr-Commit-Position: refs/heads/master@{#478864}

[modify] https://crrev.com/b5cd8f14b7d6df9fd446db36661bfefa19e4e080/tools/metrics/histograms/histograms.xml

It seems like expecting storing timestamps on xattrs always is a bad assumption with the information we have, and deleting user data because we failed to store timestamp seems like a bad tradeoff.

How about not failing in this case (maybe count the occurrence of this) but fail-safe with the wrong timestamp.

In this case we aren't failing to store the timestamps, we're failing to store the xattrs originally present on the file.  I think at this point the best option is to talk to the security folks about setting a upper limit on mark-of-the-web annotations and truncating when we find things longer than that.  Will reach out to them.

Requesting merge of https://chromium-review.googlesource.com/c/538454/ to skip quarantine xattrs which aren't used on chromeOS anyway.

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please add appropriate OSs.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/6a8305d361c3f0b4fde05fd86267a7cd9fa956ac

commit 6a8305d361c3f0b4fde05fd86267a7cd9fa956ac
Author: Dan Spaid <dspaid@google.com>
Date: Tue Jun 27 01:51:58 2017

cryptohome: Do not migrate quarantine xattrs.

Chrome sets user.xdg.origin.url and user.xdg.referrer.url on any
downloaded files.  These are not actually used in ChromeOS, and may
cause the migration to fail if they are too long.  Skip them during the
migration.

TEST=cros_workon_make --board=samus --test cryptohome
BUG= chromium:728970 

Change-Id: I4dbfe857d2b0536dd36330619b04ac9ce8f702e2
Reviewed-on: https://chromium-review.googlesource.com/538454
Commit-Ready: Dan Spaid <dspaid@chromium.org>
Tested-by: Dan Spaid <dspaid@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
(cherry picked from commit f4582035277268368d74ab42accb6a0888df6f65)
Reviewed-on: https://chromium-review.googlesource.com/549435
Reviewed-by: Dan Spaid <dspaid@chromium.org>
Commit-Queue: Dan Spaid <dspaid@chromium.org>

[modify] https://crrev.com/6a8305d361c3f0b4fde05fd86267a7cd9fa956ac/cryptohome/dircrypto_data_migrator/migration_helper.cc
[modify] https://crrev.com/6a8305d361c3f0b4fde05fd86267a7cd9fa956ac/cryptohome/dircrypto_data_migrator/migration_helper.h
[modify] https://crrev.com/6a8305d361c3f0b4fde05fd86267a7cd9fa956ac/cryptohome/dircrypto_data_migrator/migration_helper_unittest.cc

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

no need to merge to M59 anymore.