Bug 618062

Summary: [LTC 6.0 FEAT] 201252: parted support (GPT, etc) for 4K Byte Sector data disk
Product: Red Hat Enterprise Linux 6 Reporter: Ryan Lerch <rlerch>
Component: doc-Storage_Admin_GuideAssignee: Jacquelynn East <jeast>
Status: CLOSED NOTABUG QA Contact: ecs-bugs
Severity: high Docs Contact:
Priority: high    
Version: 6.1CC: borgan, bugproxy, charles_rose, coughlan, cward, ddomingo, ddumas, ejratl, esandeen, hdegoede, jeast, jfeeney, jjarvis, jmoyer, kzak, martinez, matt_domsch, meyering, mgahagan, msnitzer, peterm, qcai, rlandman, rlerch, rwheeler, snagar, wwlinuxengineering, yanwang
Target Milestone: rcKeywords: Documentation, FutureFeature
Target Release: 6.1   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 614404 Environment:
Last Closed: 2010-12-10 15:26:07 UTC Type: ---
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: 487227, 539553, 614404    
Bug Blocks: 356741, 463632, 519834, 523313, 534151, 554529, 554559, 576381, 654869, 696265    

Description Ryan Lerch 2010-07-25 22:54:21 UTC
+++ This bug was initially created as a clone of Bug #614404 +++

+++ This bug was initially created as a clone of Bug #463632 +++

=Comment: #0=================================================
Emily J. Ratliff <emilyr.com> - 2008-09-16 18:09 EDT
1. Feature Overview:
Feature Id:	[201252]
a. Name of Feature:	4K Byte Sector HDDs Support
b. Feature Description
The SCSI core disk driver appears to already have support for multiple sector sizes. Tools,
filesystem and other driver updates may be required to ensure the 4K sector size HDDs function and
perform correctly. Will need to confirm when 4k sector HDDs are available for testing. Adding a new
4K drive to a system will be the same as adding a 512 byte sector drive.

Additional Comments:	Validation only feature.

--- Additional comment from rwheeler on 2010-07-02 13:56:32 EDT ---

Can you provide specifics on the type of drive tested?

Thanks!

--- Additional comment from bugproxy.com on 2010-07-02 14:41:42 EDT ---

------- Comment From bigmach.com 2010-07-02 14:32 EDT-------
I must apologize - I thought the system I was using to test was running rhel6
beta2, but it was actually an earlier snapshot.  I upgraded to beta2 and
re-tested, and things appear to be somewhat better.  For one thing, parted no
longer hangs and allows me to put a msdos disklabel on the disk.  If I try to
put a GPT disklabel on it, I get Input/Output errors writing to the backup GPT
table, but if I ignore them parted appears to be willing to proceed using just
the primary table.  This suggests that the calculation of the end of the disk
may be incorrect in parted.  I no longer see the errors I reported in dmesg,
but instead I see "Bad block number requested", and I/O errors for high sector
numbers.

From /proc/scsi/scsi for the disk I'm using:

Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: IBM-ESXS Model: CBRCA300C3ETS0 N Rev: C370
Type:   Direct-Access                    ANSI  SCSI revision: 06

--- Additional comment from jmoyer on 2010-07-13 16:15:31 EDT ---

What is the size of the disk?  What are the expected number of sectors and what sector is parted trying to read?  I'd like to narrow down whether the problem is in the kernel misreporting the size or parted miscalculating an offset.

Thanks.

--- Additional comment from bugproxy.com on 2010-07-13 18:00:48 EDT ---

------- Comment From bigmach.com 2010-07-13 17:53 EDT-------
(In reply to comment #19)
> What is the size of the disk?  What are the expected number of sectors and what
> sector is parted trying to read?  I'd like to narrow down whether the problem
> is in the kernel misreporting the size or parted miscalculating an offset.

When the disk is plugged in, the kernel generates these messages:

sd 0:0:1:0: Attached scsi generic sg1 type 0
sd 0:0:1:0: [sdb] 73242188 4096-byte logical blocks: (300 GB/279 GiB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Mode Sense: db 00 10 08
sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:0:1:0: [sdb] 73242188 4096-byte logical blocks: (300 GB/279 GiB)
sdb: unknown partition table
sd 0:0:1:0: [sdb] 73242188 4096-byte logical blocks: (300 GB/279 GiB)
sd 0:0:1:0: [sdb] Attached SCSI disk

Then if I examine the disk with fdisk, I get this:

# fdisk -l /dev/sdb
Note: sector size is 4096 (not 512)

Disk /dev/sdb: 300.0 GB, 300000002048 bytes
255 heads, 63 sectors/track, 4559 cylinders
Units = cylinders of 16065 * 4096 = 65802240 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Unfortunately I no longer seem to be able to run parted on the disk - earlier I was able to and that's when I saw the errors about reading the backup GPT table.  Now parted just hangs after printing the warning about the 4K sector size.  According to strace, it's hanging in fsync() just like before.

--- Additional comment from hdegoede on 2010-07-20 03:47:00 EDT ---

Given the lack of hardware access for 4k *logical* sector disks, I don't think it is realistic to try and fix this for 6.0. Luckily these disks are not yet available to the generic public (which is also sort of the problem), so I think it is ok to move this to 6.1 .

--- Additional comment from msnitzer on 2010-07-20 08:58:18 EDT ---

We can avoid parted entirely given that 6.0 only supports "native" 4K devices for data volumes (non-root device).  My understanding is fdisk works perfectly well on "native" 4K devices (GPT included).

We should document the recommendation of fdisk for 4K data devices in the storage admin guide (and release notes).

Comment 4 Jacquelynn East 2010-11-11 03:59:04 UTC
Thanks for the tip :)

hdegoede see above comments please :)

Thanks

Comment 8 Jim Meyering 2010-11-16 08:40:29 UTC
I have tested with at least three different 4KB-logical sector devices.
As far as I know, there is no problem with upstream parted vs. >512B-sector devices.  If anyone has evidence to the contrary, please describe it here.

Comment 10 Mike Snitzer 2010-11-16 16:05:29 UTC
(In reply to comment #8)
> I have tested with at least three different 4KB-logical sector devices.
> As far as I know, there is no problem with upstream parted vs. >512B-sector
> devices.  If anyone has evidence to the contrary, please describe it here.

That is great, but can you help backport the required fixes to resolve bug# 614404 ?

Comment 11 Jim Meyering 2010-11-16 16:32:13 UTC
(In reply to comment #10)
> That is great, but can you help backport the required fixes to resolve bug#
> 614404 ?

Hi Mike,
In that bug, the comment "hanging in fsync()" does not sound like something that could indicate a bug in parted.  Rather, it sounds like a bug in a driver, hardware, or the kernel.  Has anyone else been able to reproduce such a failure?

Comment 12 Jim Meyering 2010-11-16 18:09:33 UTC
(In reply to comment #10)
> That is great, but can you help backport the required fixes to resolve bug#
> 614404 ?

To answer your question, Sure.
If there's a parted bug behind bug# 614404, I will help fix it.
IMHO, this should be "needinfo: reproducer required", and if none
is forthcoming in say a month or two, just close the bug.

Nothing I can see above suggests a bug in parted.
Another example, the I/O errors mentioned in the description above are unlikely to be due to bugs in Parted.

Comment 13 Mike Snitzer 2010-11-16 19:45:49 UTC
(In reply to comment #12)
> (In reply to comment #10)
> > That is great, but can you help backport the required fixes to resolve bug#
> > 614404 ?
> 
> To answer your question, Sure.
> If there's a parted bug behind bug# 614404, I will help fix it.
> IMHO, this should be "needinfo: reproducer required", and if none
> is forthcoming in say a month or two, just close the bug.
> 
> Nothing I can see above suggests a bug in parted.
> Another example, the I/O errors mentioned in the description above are unlikely
> to be due to bugs in Parted.

Fine, but I'm missing why we're laboring over that BZ here.

Comment 14 Jim Meyering 2010-11-16 20:47:20 UTC
(In reply to comment #13)
> Fine, but I'm missing why we're laboring over that BZ here.

Hi Mike,

This bug is a clone of 614404, and comments from 614404 have been the basis of all comments in this BZ.  As far as I'm concerned, both this bug and 614404
should be closed soon (as "unreproducible"), if we see no additional data.
I've marked my calendar to close both on Dec 7th if nothing comes up
in the mean time.

Comment 15 Jim Meyering 2010-12-10 15:26:07 UTC
Since there is no evidence of a bug in parted, and hence no reason to deprecate it in the RHEL6 storage guide, I'm closing this.

If anyone provides details, you're welcome to reopen.