[Nexus 7 (2013) General] sfhub:
I added the JSS15J->JSS15Q AOSP changelog to the first post:

http://funkyandroid.com/aosp-JSS15J-JSS15Q.html

Of particular interest is this entry:

42adc5a : Remove noauto_da_alloc and add nomblk_io_submit for safer eMMC Add errors=panic for better recovery

So it appears they made this change for "safer eMMC" which is usually code word for we were seeing data corruption so we had to turn off these "advanced" options.

I went back and compared the mount options between JWR66N and JSS15Q

JWR66N

/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,data=ordered 0 0

/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,data=ordered 0 0​

JSS15Q

/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,errors=panic,data=ordered 0 0

/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,errors=panic,data=ordered 0 0​

and indeed they did change the ext4 mount options on /data and /cache

In case you are curious:

auto_da_alloc is a feature of the linux kernel ext4 support where it allocates files immediately rather than delayed allocation to avoid issues with data corruption when something unexpected happens like a crash

noauto_da_alloc (JWR66N mount option) then would be to disable the default auto_da_alloc behavior and allow delayed file allocation under all circumstances, presumably for a some performance gain

However with the random reboots that are happening with the Nexus 7 2013, this likely was leading to data corruption.

Those I'm stuck on X and UIDs are inconsistent, are you feeling lucky errors will probably be reduced or mitigated with this change.

mblk_io_submit (Multiple Page-IO Submissions) is a performance which allows larger chunks of data to be submitted. There are references to this causing some data corruption is certain cases. In JSS15J, they disabled this feature. It is possible they did this just to be safe, or they were really seeing data corruption.

In any event, these changes should reduce the cases of data corruption and possibly reduce some (but not necessarily all) of the reboots if they were caused by corrupted data.

So we should see less of

help, I'm stuck on X

UIDs inconsistent, are you feeling lucky

problems, but possibly we will see slightly less disk performance as a tradeoff.

On the other hand the errors=panic could lead to more reboot situations, but there will likely be log entries to detect these situations so Google can gauge where the issues are.

This could also possibly explain the data corruption in /system where some units can not apply the OTA update because their file didn't pass the SHA1 check. I recall some units were crashing even during that initial OTA install.

UPDATE:

Of further interest is this entry:

ed93853 : flo: update prebuilt kernel, DO NOT MERGE

flo: update prebuilt kernel, DO NOT MERGE

8b7a6fb flo: mmc: disable pack feature for Hynix part

Bug: 9971949​

Pack feature is a performance enhancement where they group a bunch of reads or writes into one operation.

That they are disabling it for the Hynix (samsung) eMMC part could mean that it is not functioning correctly (ie corruption) for the Hynix part. If they source eMMC from multiple vendors, this could mean that just the ones with the Hynix part are not working correctly with pack and could explain why some people are seeing more corruption than others.

UPDATE2:

Even more workarounds for Hynix eMMC part. Discard/trim brings back memories of eMMC corruption on Samsung GS2

237604e flo: mmc workaround: add dummy read before discard/trim on some eMMC

flo: mmc workaround: add dummy read before discard/trim on some eMMC

BUG ID: 9583949
​