Bug 1314687 - 4.4.x kernel reports wrong discard_granularity
4.4.x kernel reports wrong discard_granularity
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: fedora-kernel-block
Fedora Extras Quality Assurance
Depends On:
Blocks: 1313377
  Show dependency treegraph
Reported: 2016-03-04 04:14 EST by Till Maas
Modified: 2016-09-26 06:55 EDT (History)
10 users (show)

See Also:
Fixed In Version: 4.7.4-100.fc23.x86_64
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-09-26 06:55:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Till Maas 2016-03-04 04:14:51 EST
Description of problem:
See bug 1313377

Instead of reporting 4096, the kernel reports 1 for
cat /sys/dev/block/8:0/queue/discard_granularity

Version-Release number of selected component (if applicable):

Not affected: 4.3.5-300.fc23.x86_64

Additional info:
This makes lvremove not discard logical volumes, since it assumes that the granularity is always bigger or equal to 512 for devices supporting discard/trim.
Comment 1 Mike Snitzer 2016-03-04 10:25:03 EST
Please see: https://www.redhat.com/archives/dm-devel/2016-March/msg00030.html
Comment 2 Mike Snitzer 2016-03-04 10:28:26 EST
Can you confirm whether or not your underlying SCSI device supports LBPRZ?

Please report what you have in: /sys/block/<scsi_dev_name>/queue/discard_zeroes_data
Comment 3 Till Maas 2016-03-04 11:10:58 EST
$ cat /sys/block/sda/queue/discard_zeroes_data

Does this meant that LBPRZ is supported? What does LBPRZ mean? Is it something like Read Zero After Trim (RZAT)?
Comment 4 Scott Mcdermott 2016-04-03 18:55:04 EDT
I use Debian but this has happened to me also.  Their kernel 4.3.3-7
correctly reports 512 as the discard_granularity (although, my understanding
is that the hardware actually has 8k erase blocks), while kernel 4.4.6-1
reports discard_granularity 1.  This then causes the device-mapper to report:

	discard granularity unexpectedly less than sector size

According to the vendor data sheet, the device does in fact zero discarded
blocks.  This concurs with /sys/block/sda/queue/discard_zeroes_data on
my device ('1').

Model Family:     Intel X18-M/X25-M/X25-V G2 SSDs
Device Model:     INTEL SSDSA2M160G2GC
Firmware Version: 2CV102M3
User Capacity:    160,041,885,696 bytes [160 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
ATA Version is:   ATA/ATAPI-7 T13/1532D revision 1
SATA Version is:  SATA 2.6, 3.0 Gb/s

I cannot seem to find the data sheet now, but I remember looking for it before
when determining if I needed to overwrite the blocks or not to sanitize it.
Comment 5 Laura Abbott 2016-09-23 15:47:53 EDT
*********** MASS BUG UPDATE **************
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
If you experience different issues, please open a new bug report for those.
Comment 6 Till Maas 2016-09-26 06:55:58 EDT
kernel 4.7.4-100.fc23.x86_64 reports 512, thank you for fixing it:
$ cat /sys/dev/block/8:0/queue/discard_granularity

Note You need to log in before you can comment on or make changes to this bug.