On 2010/02/14 20:58 (GMT+0100) nodata composed:

On 14/02/10 17:59, Neal Becker wrote:

...

Any truth here?

...

http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096-Byte_Sec...

Yep. But you can align the partition tables to get better results, i.e. don't except the default start value that fdisk gives you.

Don't accept the default value either, or use a smarter partitioner than fdisk. :-)

...

...

Yep. But you can align the partition tables to get better results ...

Does/will the standard Fedora installer act intelligently?

I have seen evidence that partitioning by anaconda is aware of some relevant properties of recent hardware. Anaconda-13.25 set the drive geometry of a USB2.0 flash memory device (with 512 bytes/sector) to 62 sectors/track by 128 heads (tracks/cylinder) instead of 63x225 (which was the previous default, using the maximum values). Thus a "cylinder" already is divisible by 256 sectors, or 2**17 bytes, which equals the size of an erase block in many flash devices. This guarantees that an aligned 4KiB block never crosses the boundary between two erase blocks, and therefore avoids penalties when re-writing. The downside is that the total number of "cylinders" doubles, and requires another bit to describe.

--

Ric Wheeler wrote:

On 02/14/2010 11:59 AM, Neal Becker wrote:

...

Any truth here?

http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096- Byte_Sector_Hard_Drives

We have actually been working hard to take advantage of the information that these drives export so hopefully this will all work in f13 to make sure that we align partitions and do IO in sizes supported by the drive (i.e., 4KB for these drives).

Martin Petersen's comment on the article http://www.osnews.com/thread?409410

is pretty clear, explaining what seems to have happened to this particular tester with this particular drive.

Note also this gem: "Caveat being that Fedora is the only community distribution I know of that's using the updated bits. I don't think all of them made it into Fedora 12 but I'm sure Fedora 13 will do the right thing."

Several people have been working hard, from the kernel, up to partitioning tools and on up to mkfs, to handle these drives.

-Eric

nodata wrote:

On 15/02/10 01:20, Ric Wheeler wrote:

...

On 02/14/2010 11:59 AM, Neal Becker wrote:

...

Any truth here?

http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096- Byte_Sector_Hard_Drives

We have actually been working hard to take advantage of the information that these drives export

Is this the same information as shown by hdparm?

I don't know for sure if hdparm shows it; I don't think so. If you mean:

-g Display the drive geometry (cylinders, heads, sectors), the size (in sectors) of the device, and the starting offset (in sectors) of the device from the beginning of the drive.

then no...

this info is exported in sysfs for each block device:

[root@host queue]# pwd /sys/block/sdb/queue [root@host queue]# ls discard_granularity iostats nomerges rotational discard_max_bytes logical_block_size nr_requests rq_affinity discard_zeroes_data max_hw_sectors_kb optimal_io_size scheduler hw_sector_size max_sectors_kb physical_block_size iosched minimum_io_size read_ahead_kb

Many of these values are relevant to that article. Several of these values are also available via ioctl. libblkid is a nice interface to get to the values. fdisk & parted make use of it, as do mkfs.ext4 and mkfs.xfs ... etc.

Some (all?) of the values above are described in Documentation/ABI/testing/sysfs-block in the kernel tree (or kernel-doc rpm)

-Eric

On 02/15/2010 12:13 PM, Michael Cronenworth wrote:

Eric Sandeen wrote:

...

I don't know for sure if hdparm shows it; I don't think so. If you mean:

     -g     Display the drive geometry (cylinders, heads, sectors),  the
            size (in sectors) of the device, and the starting offset (in
            sectors) of the device from the beginning of the drive.

then no...

hdparm -I displays many things one of which is the following:

 Logical/Physical Sector size:           512 bytes

I haven't tried hdparm on any of these drives. Mark Lord might be ahead of the game as usual though :-)

Mark, have you updated hdparm to display the new alignment info, etc?

Ric