Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ 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.
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 .
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).
This seems to currently work for me on 6.0:
pjones8:~# parted /dev/sda
Warning: Device /dev/sda has a logical sector size of 4096. Not all parts of
GNU Parted support this at the moment, and the working code is HIGHLY
EXPERIMENTAL.
GNU Parted 2.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel
New disk label type? gpt
Warning: The existing disk label on /dev/sda will be destroyed and all data on
this disk will be lost. Do you want to continue?
Yes/No? yes
(parted) p
Model: SEAGATE ST3146356SS (scsi)
Disk /dev/sda: 163GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt
Number Start End Size File system Name Flags
(parted) mkpart
Partition name? []? "EFI System Partition"
File system type? [ext2]? FAT
parted: invalid token: FAT
File system type? [ext2]? fat16
Start? 1049kB
End? 211MB
(parted) set 1 boot on
(parted) mkpart
Partition name? []?
File system type? [ext2]?
Start? 211MB
End? 524MB
(parted) mkpart
Partition name? []?
File system type? [ext2]?
Start? 735MB
End? 163GB
(parted) p
Model: SEAGATE ST3146356SS (scsi)
Disk /dev/sda: 163GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 211MB 210MB EFI System Partition boot
2 211MB 524MB 314MB
3 735MB 163GB 162GB
(parted) q
Information: You may need to update /etc/fstab.
pjones8:~# parted /dev/sda
Warning: Device /dev/sda has a logical sector size of 4096. Not all parts of
GNU Parted support this at the moment, and the working code is HIGHLY
EXPERIMENTAL.
GNU Parted 2.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: SEAGATE ST3146356SS (scsi)
Disk /dev/sda: 163GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 211MB 210MB EFI System Partition boot
2 211MB 524MB 314MB
3 735MB 163GB 162GB
(parted) q
pjones8:~#