New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 835034 link

Starred by 2 users
Status: Assigned
Owner:
gwendal@chromium.org
Cc:
█ senj@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

kernel: eMMC: support BLKZEROOUT

Project Member Reported by gwendal@chromium.org, Apr 19 2018 
It looks like mmc stack does not support BLKZEROOUT, write_same_max_bytes is set to 0. However, since eMMC 5.1, some device can indicate that after discard operation, the data read from the discarded block will be constant (0 or 1) or not.
For those devices which returns a constant 0, we can indicate to the block layer to  send a BLKZEROOUT and map it to a discard.
[The patch will be sent upstream first]

Comment 1 by de...@google.com, Apr 23 2018 

Isn't this what BLKDISCARDZEROES query does? If so, update_engine checks that value and uses BLKDISCARD to zero out data instead of BLKZEROOUT when possible.

As far as I remember, I didn't find a device that would zero out discarded blocks.

Comment 2 by benhenry@chromium.org, Aug 3

Status: Assigned (was: Untriaged)
This bug has an owner, thus, it's been triaged. Changing status to "assigned".

Comment 3 by gwendal@chromium.org, Aug 7 

By " BLKZEROOUT", I meant "offload BLKZEROOUT". When the device does not return zero when a discard is sent, then the kernel will write 0's to the device.

A device does not have to write 0's to the discarded block. Just returns 0s when the host asks for LBA of blocks that have been discarded. Most modern ATA SSD devices that support trim do that: Samsung SSD 860, Crucial_CT960M50 on my workstation do.
►

Sign in to add a comment