Bug 1314687

Summary:	4.4.x kernel reports wrong discard_granularity
Product:	[Fedora] Fedora	Reporter:	Till Maas <opensource>
Component:	kernel	Assignee:	fedora-kernel-block
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	agk, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, msnitzer, opensource, scott
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	4.7.4-100.fc23.x86_64	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-09-26 10:55:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1313377

Description Till Maas 2016-03-04 09:14:51 UTC

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):
4.4.2-301.fc23.x86_64
4.4.3-300.fc23.x86_64 

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 15:25:03 UTC

Please see: https://www.redhat.com/archives/dm-devel/2016-March/msg00030.html

Comment 2 Mike Snitzer 2016-03-04 15:28:26 UTC

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 16:10:58 UTC

$ cat /sys/block/sda/queue/discard_zeroes_data
1


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 22:55:04 UTC

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 19:47:53 UTC

*********** 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 10:55:58 UTC

kernel 4.7.4-100.fc23.x86_64 reports 512, thank you for fixing it:
$ cat /sys/dev/block/8:0/queue/discard_granularity
512