Why 4k native drives haven't arrived

Why 4k native drives haven't arrived

[Stan Hoeppner]

Until someone demonstrates otherwise I will continue to state that 4K
native drives are still not on the open market.  And the reason for this
is quite logical if given a moment of thought.

Advanced Format 512e drives, drives with 4K native sectors but 512B
sectors presented to the host, fully accomplished the goal of the
spinning disk drive manufacturers.  That goal was simply to pack more
data per platter, on average about 11% more, by reducing the amount of
bits consumed for ECC.  I.e. they can sell a lager capacity drive using
the same hardware as a native 512 byte/sector drive, or with some drive
capacities, reduce the number of platters while maintaining the same
capacity, thus reducing component and production cost, and hopefully
retail price.

The physical sector size presented to the host is irrelevant to the
drive manufacturers, given the singular goal above.  Switching to a
native 4K sector does not benefit the manufacturers.  At the current
time it actually will cause them tremendous problems.

If they were to put 4K native drives on the market today, many millions
of Windows XP users would buy the drives, ignoring, or simply not
reading far enough to find the "4K native" warnings.  They then return
the drives when they don't work, causing great ill will, bad reviews
tarnishing manufacturers' reputations, and decreasing repeat business.
Thus native 4K drives will not be on the open market until the
manufacturers are comfortable that most legacy machines have been
retired, eliminating the possibility of the scenario above.

The first units of native 4K drives will be, or possibly already have
been, to OEMs who exercise control over which systems and disk arrays in
which the drives will be installed.  This prevents such a problem in the
enterprise space, as purchasers typically rely on their vendors to do
compatibility matching.  Enterprise OEMs have long maintained such
product compatibility databases.

-- 
Stan

Re: Why 4k native drives haven't arrived

[Mikael Abrahamsson]

On Thu, 2 Jan 2014, Stan Hoeppner wrote:

> The first units of native 4K drives will be, or possibly already have 
> been, to OEMs who exercise control over which systems and disk arrays in 
> which the drives will be installed.  This prevents such a problem in the 
> enterprise space, as purchasers typically rely on their vendors to do 
> compatibility matching.  Enterprise OEMs have long maintained such 
> product compatibility databases.

I fully agree with your analysis. I am sure there are lots of BIOS, 
controllers etc that have lots of bugs with 4k native drives, so even if 
the OS and tools supports it, there will be other issues.

On the other hand, if the 512 byte sectors are properly aligned so that 
the 4k page size always are written as 8 contigous sectors, then what does 
native 4k sector really give us? Lower IRQ rates? This is probably an 
additional reason why they haven't arrived. It's a complete ecosystem and 
taking the first step has huge downsides.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: Why 4k native drives haven't arrived

[Dimitri John Ledkov]

On 3 January 2014 01:53, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> Until someone demonstrates otherwise I will continue to state that 4K
> native drives are still not on the open market.  And the reason for this
> is quite logical if given a moment of thought.
>
> Advanced Format 512e drives, drives with 4K native sectors but 512B
> sectors presented to the host, fully accomplished the goal of the
> spinning disk drive manufacturers.  That goal was simply to pack more
> data per platter, on average about 11% more, by reducing the amount of
> bits consumed for ECC.  I.e. they can sell a lager capacity drive using
> the same hardware as a native 512 byte/sector drive, or with some drive
> capacities, reduce the number of platters while maintaining the same
> capacity, thus reducing component and production cost, and hopefully
> retail price.
>
> The physical sector size presented to the host is irrelevant to the
> drive manufacturers, given the singular goal above.  Switching to a
> native 4K sector does not benefit the manufacturers.  At the current
> time it actually will cause them tremendous problems.
>
> If they were to put 4K native drives on the market today, many millions
> of Windows XP users would buy the drives, ignoring, or simply not
> reading far enough to find the "4K native" warnings.  They then return
> the drives when they don't work, causing great ill will, bad reviews
> tarnishing manufacturers' reputations, and decreasing repeat business.
> Thus native 4K drives will not be on the open market until the
> manufacturers are comfortable that most legacy machines have been
> retired, eliminating the possibility of the scenario above.
>

I'm confused how Windows XP is relevant to the latest top-grade server
hard-drives. And vice versa =)

I would have thought it's more likely for Windows XP users not to buy
hardware components, given that clearly those users are not upgrade
savy in any shape or form.
And even if one would buy a 4k native drive, i would have thought
there'd be other obstacles in trying it out e.g. not having a SATA
port =) considering it was created two years after Windows XP =) or
since a 4k native drive is likely to be 2TB+ in size, GPT support is
required to address the whole drive...

The target market of 4k native drives at the moment is not consumer
market, where SSDs are dominating as "premium" components.
Instead the target market for 4k native drives is server / enterprise
with never-decreasing storage requirements.

FYI here is Microsoft policy with respect to native 4k support matrix:
http://support.microsoft.com/kb/2510009

> The first units of native 4K drives will be, or possibly already have
> been, to OEMs who exercise control over which systems and disk arrays in
> which the drives will be installed.  This prevents such a problem in the
> enterprise space, as purchasers typically rely on their vendors to do
> compatibility matching.  Enterprise OEMs have long maintained such
> product compatibility databases.
>

Most Segate/Baracuda units of capacities close to 1TB and higher are
4k native. And since ~2010-2012 there has been an ever increasing
amount of request for support of native 4k in linux installers which
is as good indication of the uptake as it gets.

I guess eventually it will also tickle down to more conventional
hardware setups.

-- 
Regards,

Dimitri.

Re: Why 4k native drives haven't arrived

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/03/2014 06:27 AM, Dimitri John Ledkov wrote:
> And even if one would buy a 4k native drive, i would have thought 
> there'd be other obstacles in trying it out e.g. not having a SATA 
> port =) considering it was created two years after Windows XP =)
> or since a 4k native drive is likely to be 2TB+ in size, GPT
> support is required to address the whole drive...

Actually, 4k native drives can use MBR up to 16 TB.  The limitation on
the MBR partition table is 32 bits to address sectors, so larger
sectors => higher addressable size.  Some of the fakeraid controllers
on the market take advantage of this fact and report a 1k or 2k
physical sector size to allow MBR partitioning on larger arrays.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJS4Hw2AAoJEI5FoCIzSKrwX5YH/joOvhkO9wHpZOgbCfPhTvzC
Zax4nNuv9m0jAHzx+D0jqWzq/maf6ju0Xu3Sc49Iyy1ZfCeNXe64KrLnXyF2He9W
TMMqDoAe0pIqdSxMtLr/1G/kJa1pxIcaoYvtc2val3MPxz/dw32XFk60fyBBSGYC
n5f2Hs1TB4H0uo1gE4ywtN+fLtAQoqhZpHYIb0rS26zdwMJ3ho3qKwJeONy4FkhQ
pKh4TTJBBMKe/Iz4v4+5RP+yq3Jlx860c+CMHq8amtGHPiBmGBL4WpE6lul/MHGn
WBBv0g/VNd5M7K9Q/g01sIIRwyFisEImMmvamC9ctsUlcFzMEtkRfRyM1C+2SfU=
=bHlp
-----END PGP SIGNATURE-----

Re: Why 4k native drives haven't arrived

[Martin K. Petersen]

>>>>> "Stan" == Stan Hoeppner <stan@hardwarefreak.com> writes:

Stan,

Stan> Advanced Format 512e drives, drives with 4K native sectors but
Stan> 512B sectors presented to the host, 

Ignoring ECC, legacy/native drives have a 1:1 mapping between logical
and physical block sizes (512/520/528 bytes).

512e drives have a 512-byte logical block size. That's what the host
operating system uses for addressing purposes when filling out the
command to the disk. Internally, they use 4096-byte physical blocks on
media.

Drives with 4096-byte logical *and* physical blocks are slowly becoming
available. These drives are referred to as 4Kn (4K native) drives. So be
careful about using the term "native" when referring to the physical
sector size.

Linux supports drives with logical block sizes up to the system page
size. This means we support 4Kn drives and have for over a decade. DASD
on the mainframe is 4Kn, for instance. And there are a bunch of SAN
devices and SSDs out there that also report themselves as 4Kn. So
devices absolutely exist and are available.

4Kn harddrives are harder to come by, however. SAS/FC drives are
available formatted as 4Kn when you order them. Some 512n drives can be
reformatted. But you won't find 4Kn formatted drives in retail.

4Kn SATA works fine in Linux as well but has failed to get any
traction. Mainly because there is no win for the user. Just lots of
pain.


Stan> The physical sector size presented to the host is irrelevant to
Stan> the drive manufacturers, given the singular goal above.  Switching
Stan> to a native 4K sector does not benefit the manufacturers.  At the
Stan> current time it actually will cause them tremendous problems.

The drive vendors pushed 4Kn for years and years. The problem was that
to the host there is no benefit whatsoever. Just lots of pain throughout
the entire I/O stack (BIOS, OS, HBA ROMs, RAID controller firmware). And
no win. None.

So the drive vendors begrudgingly did 512e as a transitional thing. But
they would like nothing more than killing off read-modify-write handling
in their firmware/ASICs.

We are sticking with 512-byte logical/physical blocks for server
workloads for several reasons. First of all it's important to have
predictable performance. The read-modify-write cycles for misaligned
writes on 512e drives can severely impact performance.

The second reason is data integrity preservation. None of the consumer
512e drives feature protection against sibling block corruption during
read-modify-write. The nasty thing here is that a partial block write
can end up garbling logical blocks within the 4KB physical sector that
were not part of the failed I/O request. This is an absolute no-go from
a data integrity perspective.

Therefore server drives have two options: Native (512n up to a certain
capacity point, 4Kn for larger drives), or 512e with flash, supercaps or
other tech that'll allow the drive to complete a partial block write
during power failure. Both are out there.


Stan> Thus native 4K drives will not be on the open market until the
Stan> manufacturers are comfortable that most legacy machines have been
Stan> retired, eliminating the possibility of the scenario above.

Actually, >2TB USB drives typically expose 4Kn to the host. For that
reason there are already problems with XP and big drives.

PS. See also: https://oss.oracle.com/~mkp/docs/linux-advanced-storage.pdf

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Why 4k native drives haven't arrived

[Stan Hoeppner]

On 1/3/2014 3:04 PM, Martin K. Petersen wrote:
>>>>>> "Stan" == Stan Hoeppner <stan@hardwarefreak.com> writes:
> 
> Stan,
> 
> Stan> Advanced Format 512e drives, drives with 4K native sectors but
> Stan> 512B sectors presented to the host, 
> 
> Ignoring ECC, legacy/native drives have a 1:1 mapping between logical
> and physical block sizes (512/520/528 bytes).
> 
> 512e drives have a 512-byte logical block size. That's what the host
> operating system uses for addressing purposes when filling out the
> command to the disk. Internally, they use 4096-byte physical blocks on
> media.
> 
> Drives with 4096-byte logical *and* physical blocks are slowly becoming
> available. These drives are referred to as 4Kn (4K native) drives. So be
> careful about using the term "native" when referring to the physical
> sector size.

My exact statement above leaves no doubt.  But your point is duly noted,
and I'll make sure I use "logical" and "physical" in the future.

> Linux supports drives with logical block sizes up to the system page
> size. This means we support 4Kn drives and have for over a decade. DASD
> on the mainframe is 4Kn, for instance. And there are a bunch of SAN
> devices and SSDs out there that also report themselves as 4Kn. So
> devices absolutely exist and are available.
> 
> 4Kn harddrives are harder to come by, however. SAS/FC drives are
> available formatted as 4Kn when you order them. Some 512n drives can be
> reformatted. But you won't find 4Kn formatted drives in retail.
> 
> 4Kn SATA works fine in Linux as well but has failed to get any
> traction. Mainly because there is no win for the user. Just lots of
> pain.

I agree for the most part, and I was a vocal critic of the whole 4K push
when it started, and especially of 512e.  But as the throughput of
drives increases, 4K host transfers with 4Kn drives will pay some
performance dividends, though obviously nothing dramatic.  So it's not
completely bleak.

> Stan> The physical sector size presented to the host is irrelevant to
> Stan> the drive manufacturers, given the singular goal above.  Switching
> Stan> to a native 4K sector does not benefit the manufacturers.  At the
> Stan> current time it actually will cause them tremendous problems.
> 
> The drive vendors pushed 4Kn for years and years. The problem was that
> to the host there is no benefit whatsoever. Just lots of pain throughout
> the entire I/O stack (BIOS, OS, HBA ROMs, RAID controller firmware). And
> no win. None.
> 
> So the drive vendors begrudgingly did 512e as a transitional thing. But
> they would like nothing more than killing off read-modify-write handling
> in their firmware/ASICs.

I'm sure they would but is this a high priority?  RMW handling was a
small price to pay for the increased platter density they were after.
And now that most modern OS partitioning tools align to 1MB this isn't a
performance issue for the user.  Does the RMW code occupy a huge amount
of the firmware space on the drive, or continual sink of engineering
dollars with each new drive model?

I'm of the impression than 512e is done, is taking no additional money
out of the drive vendors' pockets, yet increasing net dollars due to
larger drive capacities, and fewer platters needed on some smaller
drives.  This is why I said there is little motivation on the part of
the drive vendors to continue pushing 4Kn drives.

Whether 512B or 4KB it's obviously preferable to everyone to have the
logical and physical block sizes match--vendors, OS kernel programmers,
users.

> We are sticking with 512-byte logical/physical blocks for server
> workloads for several reasons. First of all it's important to have
> predictable performance. The read-modify-write cycles for misaligned
> writes on 512e drives can severely impact performance.
>
> The second reason is data integrity preservation. None of the consumer
> 512e drives feature protection against sibling block corruption during
> read-modify-write. The nasty thing here is that a partial block write
> can end up garbling logical blocks within the 4KB physical sector that
> were not part of the failed I/O request. This is an absolute no-go from
> a data integrity perspective.
>
> Therefore server drives have two options: Native (512n up to a certain
> capacity point, 4Kn for larger drives), or 512e with flash, supercaps or
> other tech that'll allow the drive to complete a partial block write
> during power failure. Both are out there.

Note that I've presented counterpoints here simply for technical
discussion.  I'm no fan of 512e, never have been, never will be, have
never used a 512e drive, and never will, not if I can void it.  I'm
still a 512n kinda guy.

> Stan> Thus native 4K drives will not be on the open market until the
> Stan> manufacturers are comfortable that most legacy machines have been
> Stan> retired, eliminating the possibility of the scenario above.
> 
> Actually, >2TB USB drives typically expose 4Kn to the host. For that
> reason there are already problems with XP and big drives.

http://support.microsoft.com/kb/2510009

Windows 7 doesn't support 4Kn drives either.  Up to now I thought it was
limited to XP.  Since these two versions of Windows make up ~80% of the
installed MS Windows base, putting 4Kn USB drives on the market *is*
suicide.

> PS. See also: https://oss.oracle.com/~mkp/docs/linux-advanced-storage.pdf

Interesting read.  Are the suggested IDENTIFY DEVICE responses simply a
reprint of the ATA/SCSI standards, or are these return values Linux
specific, as the paper seems to suggest?  I assume they're standard, as
the vendors would most likely code for Windows if it required different
values.

-- 
Stan

Re: Why 4k native drives haven't arrived

[Martin K. Petersen]

>>>>> "Stan" == Stan Hoeppner <stan@hardwarefreak.com> writes:

Stan> I'm sure they would but is this a high priority?  RMW handling was
Stan> a small price to pay for the increased platter density they were
Stan> after.  And now that most modern OS partitioning tools align to
Stan> 1MB this isn't a performance issue for the user.  Does the RMW
Stan> code occupy a huge amount of the firmware space on the drive, or
Stan> continual sink of engineering dollars with each new drive model?

It certainly takes up resources and puts constraints on the inner
workings of the drive firmware. They really don't want to be in the RMW
business but I doubt that's going to change.

SMR drives are closer to tape and a big departure from decades of
harddrive behavior. The current plan is to have cheap drive models that
are essentially glorified tapes and where the OS and filesystem have to
explicitly manage the zones. Misaligned or I/Os requiring RMW will
simply be rejected.

More expensive and backwards-compatible SMR drives will be doing the RMW
transparently in firmware. However, this comes at a much higher cost
than for 512e. SMR zones are 256MB - 1GB. That's a big chunk of stuff to
RMW!

My hunch is that in reality we'll land somewhere in-between the two
approaches like we did for 512e. In Linux we essentially treat 512e
drives as 4Kn in the I/O stack. And we are careful to get alignment
right. But legacy applications that rely on 512-byte accesses (using
direct I/O for instance) still work.

I think we'll see something similar with SMR. We'll query the drive
topology, and filesystems that are conductive to the SMR approach like
btrfs will properly align to the zones and only append to them. Whereas
legacy filesystems will resort to letting the drive deal with the
horrors.

Stan> This is why I said there is little motivation on the part of the
Stan> drive vendors to continue pushing 4Kn drives.

They are pushing pretty hard, actually, but there is a lot of inertia
and legacy hardware/software out there. The industry 4Kn transition was
originally supposed to be completed around late 2006!

Stan> Windows 7 doesn't support 4Kn drives either.  Up to now I thought
Stan> it was limited to XP.  Since these two versions of Windows make up
Stan> ~80% of the installed MS Windows base, putting 4Kn USB drives on
Stan> the market *is* suicide.

I believe Windows treats USB and SATA/SCSI differently. But I have no
personal experience in the Windows department.

Off-the-shelf 4TB USB drive:

# lsscsi | grep sdc
[10:0:0:0]   disk    Seagate  Backup+ Desk     050B  /dev/sdc
# sg_readcap -l /dev/sdc | grep length
   Logical block length=4096 bytes

(I'm guessing it's actually a 512e drive and that it's the SATA-USB
bridge that makes it look like 4Kn to the host. But who knows?).

Stan> Interesting read.  Are the suggested IDENTIFY DEVICE responses
Stan> simply a reprint of the ATA/SCSI standards, or are these return
Stan> values Linux specific, as the paper seems to suggest?  

The document describes the drive parameters I key off of in sd and
libata. We only use a small subset of what T10/T13 allows in Linux. The
document is what we share with drive vendors to make sure they implement
the knobs Linux needs correctly.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Why 4k native drives haven't arrived

[Peter Grandi]

[ ... ]

> DASD on the mainframe is 4Kn, for instance. And there are a
> bunch of SAN devices and SSDs out there that also report
> themselves as 4Kn.

Some HW RAID host adapters can be configured to offer the host
4KiB sectors too.

> So devices absolutely exist and are available. 4Kn harddrives
> are harder to come by, however. SAS/FC drives are available
> formatted as 4Kn when you order them. Some 512n drives can be
> reformatted. But you won't find 4Kn formatted drives in retail.

But as mentioned later on they have been available for
years. Also I remember buying some old generation of SATA WD
Green drive that had 4096 logical sectors, quickly superceded by
emulated drives in later updates, as major OS support some years
ago was not quite there yet.

> 4Kn SATA works fine in Linux as well but has failed to get any
> traction. Mainly because there is no win for the user. Just
> lots of pain. [ ... ] The drive vendors pushed 4Kn for years
> and years. The problem was that to the host there is no
> benefit whatsoever. Just lots of pain throughout the entire
> I/O stack (BIOS, OS, HBA ROMs, RAID controller firmware). And
> no win. None.

There are some obvious wins to addressing in 4KiB sectors, the
most important of which is the avoidance of RMW as a possibility.

But there is another important short term win, as older storage
protols and formats relate maximum disk or partition or filetree
capacity to maximum number of sectors addressable, which is
often fixed at below 2^32 or 2^31, so addresses in units of 4KiB
sectors allow 8 times more capacity than 512B ones.

This is particularly important for drives partitioned using MBR
partitions with FAT32 filetrees in them, which is why this is
the case especially for USB drives:

> [ ... ]  Actually, >2TB USB drives typically expose 4Kn to the
> host. For that reason there are already problems with XP and
> big drives.

As for example here:

  http://kb.netgear.com/app/answers/detail/a_id/22039/~/readyshare-and-usb-hard-drives-with-4kb-sector-size

and ingeneral in several reports here:

  http://www.google.com/search?btnG=SEARCH&num=100&as_epq=Logical+Sector+size+4096+bytes

Re: Why 4k native drives haven't arrived

[Martin K. Petersen]

>>>>> "Peter" == Peter Grandi <pg@lxra2.for.sabi.co.UK> writes:

Peter> There are some obvious wins to addressing in 4KiB sectors, the
Peter> most important of which is the avoidance of RMW as a possibility.

There are also drives where you can disable RMW explicitly. I.e. the
drive appears as 512e but will reject any misaligned non-multiple of 4K.

The downside to 4Kn is that it breaks applications using direct I/O that
assume that the sector size is 512 bytes. Which essentially means all of
them. Solaris opted to do RMW in software to overcome that issue.
Whereas we are trying to get application writers to fix their code...

Peter> But there is another important short term win, as older storage
Peter> protols and formats relate maximum disk or partition or filetree
Peter> capacity to maximum number of sectors addressable, which is often
Peter> fixed at below 2^32 or 2^31, so addresses in units of 4KiB
Peter> sectors allow 8 times more capacity than 512B ones.

Yep. Although in Linux we use 512-byte sectors throughout the I/O stack
regardless of the device's logical block size.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Why 4k native drives haven't arrived

[Chris Murphy]

4Kn drives, i.e. 4096 byte physical and logical sector, drives maybe have been in the wild for some time, ~1 year.

http://forums.macrumors.com/showpost.php?p=16996220&postcount=189
"Logical sector size: 4096 bytes"

And further, the LBA's are clearly 4096 bytes each based on the partition table sector start/end values only adding up to the size column if the (LBA) sectors are 4096 bytes each.

This drive is found in an enclosure, sold as a backup device, not intended for booting. 


Chris Murphy

Re: Why 4k native drives haven't arrived

[Chris Murphy]

On Jan 9, 2014, at 2:49 PM, Chris Murphy <lists@colorremedies.com> wrote:

> 4Kn drives, i.e. 4096 byte physical and logical sector, drives maybe have been in the wild for some time, ~1 year.
> 
> http://forums.macrumors.com/showpost.php?p=16996220&postcount=189
> "Logical sector size: 4096 bytes"
> 
> And further, the LBA's are clearly 4096 bytes each based on the partition table sector start/end values only adding up to the size column if the (LBA) sectors are 4096 bytes each.
> 
> This drive is found in an enclosure, sold as a backup device, not intended for booting. 

Huh. Two more cases. All three involve USB enclosures. Bug or feature? Is it possible the enclosure's bridge chipset is disabling the drive's 512-byte emulation?

https://bbs.archlinux.org/viewtopic.php?pid=1162795
http://forum.buffalo.nas-central.org/viewtopic.php?f=68&t=25201



Chris Murphy

Re: Why 4k native drives haven't arrived

[Martin K. Petersen]

>>>>> "Chris" == Chris Murphy <lists@colorremedies.com> writes:

Chris> Huh. Two more cases. All three involve USB enclosures. Bug or
Chris> feature?  

Feature.

Chris> Is it possible the enclosure's bridge chipset is disabling the
Chris> drive's 512-byte emulation?

There's nothing to disable. If the USB-SATA bridge exposes 4K logical
blocks to the host all accesses will inevitably be aligned multiples of
4K. All the bridge needs to do is adjust LBA and transfer length. Not
unlike how we handle 1/2/4Kn in the Linux SCSI disk driver given that
the block layer always uses 512-byte sectors.

The two 4Kn USB drives I have both use 512e drives internally:

# sg_readcap -l /dev/sdd | grep Logical
   Logical block length=4096 bytes
   Logical blocks per physical block exponent=0
# hdparm -I /dev/sdd | grep Sector 
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:                  0 bytes

It is conceivable that there are other USB drives out there that
actually use 4Kn drives inside but I doubt it. All the 4Kn SATA drives I
have in the lab are engineering samples...

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Why 4k native drives haven't arrived

[Martin K. Petersen]

>>>>> "Chris" == Chris Murphy <lists@colorremedies.com> writes:

Chris> I think this is a pretty craptastic thing for a vendor to do to
Chris> users. It doesn't matter that the overwhelming majority will buy
Chris> the product as a unit, and never remove it. It means some users
Chris> will need esoteric knowledge to recover their own data, a
Chris> recovery from data loss that's induced by ill conceived product
Chris> behavior.

Removing the physical drive from the USB enclosure is getting pretty far
away from "intended purpose". I don't disagree that it's useful and that
I've done so in the past. But it is purely coincidental that this
particular recovery scenario has been possible at all. We are starting
to see drives where there is no physical SATA interface on the PCB, the
drive terminates in a USB connector. And with impending disk recording
technologies, detaching a drive from any host-facing logic will
definitely be a thing of the past.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Why 4k native drives haven't arrived

[Chris Murphy]

On Jan 12, 2014, at 11:32 AM, "Martin K. Petersen" <martin.petersen@oracle.com> wrote:

>>>>>> "Chris" == Chris Murphy <lists@colorremedies.com> writes:
> 
> Chris> I think this is a pretty craptastic thing for a vendor to do to
> Chris> users. It doesn't matter that the overwhelming majority will buy
> Chris> the product as a unit, and never remove it. It means some users
> Chris> will need esoteric knowledge to recover their own data, a
> Chris> recovery from data loss that's induced by ill conceived product
> Chris> behavior.
> 
> Removing the physical drive from the USB enclosure is getting pretty far
> away from "intended purpose".

It's common enough that it's predictable that a significant minority users will get into trouble with a product of this type. That even Mac users are pulling drives out of enclosures, for reasons other than troubleshooting, further demonstrates that it's not at all uncommon practice.

> I don't disagree that it's useful and that
> I've done so in the past. But it is purely coincidental that this
> particular recovery scenario has been possible at all.

It doesn't seem to be by coincidence at all, but that doesn't even matter, it's been this way for so long that it's expected a drive in and out of an enclosure will have identical behavior with respect to size, number of sectors, and the value of those sectors.


> We are starting
> to see drives where there is no physical SATA interface on the PCB, the
> drive terminates in a USB connector.

> And with impending disk recording
> technologies, detaching a drive from any host-facing logic will
> definitely be a thing of the past.

Great. That will obviate this particular problem because there's no behavioral change in or out of the enclosure. The scenario in question, however, clearly seems half-baked and premature for almost no benefit for users.

Is there even a single GPT partitioning tool that doesn't align to at least 8-sector boundaries? So far every one of these drives in enclosures is sufficiently large that they're going to be GPT partitioned in any case.


Chris Murphy

Re: Why 4k native drives haven't arrived

[Chris Murphy]

On Jan 12, 2014, at 12:04 PM, Chris Murphy <lists@colorremedies.com> wrote:

> Is there even a single GPT partitioning tool that doesn't align to at least 8-sector boundaries? So far every one of these drives in enclosures is sufficiently large that they're going to be GPT partitioned in any case.

Another use case that explains this better than RMW avoidance, even though I still think it's a junk workflow: a single product that can be used from Windows XP 32-bit all the way to the most recent OS's, with no tricks like jumpers or specialized formatting tools.

If the manufacturer uses 4096 byte logical sectors, they can format the disk using MBR. With 4K sector sizes, MBR will support a 16TB drive.

I think this is more useful for the manufacturers with this product class, than is RMW avoidance, although such RMW avoidance is an included side benefit. It makes me wonder why we haven't seen more of these in the wild. It seems the enclosure case should be glued instead of screwed, with a warranty voided if cracked sticker to deter removal.

Chris Murphy

Re: Why 4k native drives haven't arrived

[Roman Mamedov]

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

On Sun, 12 Jan 2014 12:04:53 -0700
Chris Murphy <lists@colorremedies.com> wrote:

> 
> On Jan 12, 2014, at 11:32 AM, "Martin K. Petersen" <martin.petersen@oracle.com> wrote:
> 
> >>>>>> "Chris" == Chris Murphy <lists@colorremedies.com> writes:
> > 
> > Chris> I think this is a pretty craptastic thing for a vendor to do to
> > Chris> users. It doesn't matter that the overwhelming majority will buy
> > Chris> the product as a unit, and never remove it. It means some users
> > Chris> will need esoteric knowledge to recover their own data, a
> > Chris> recovery from data loss that's induced by ill conceived product
> > Chris> behavior.
> > 
> > Removing the physical drive from the USB enclosure is getting pretty far
> > away from "intended purpose".
> 
> It's common enough that it's predictable that a significant minority users will get into trouble with a product of this type. That even Mac users are pulling drives out of enclosures, for reasons other than troubleshooting, further demonstrates that it's not at all uncommon practice.

From what I remember reading about these drives, some of the newer ones are
just USB-only. There is no "enclosure" to speak of, that you could remove and
then simply plug the drive into SATA. It may be still possible, but certainly
not easy:
http://www.datarecoverytools.co.uk/2010/05/05/how-to-connect-and-recover-usb-only-western-digital-drives-with-hd-doctor-suite/

It does make sense for the manufacturers to roll-out these lesser-compatible
features on such USB-only drives first. Another instance where that was the
case, is the first 3 TB drives. They can manufacture and sell those with
confidence, knowing that no one will try to use the drive plugged directly into
their Windows XP PC with a 10-year-old BIOS.

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Why 4k native drives haven't arrived

[Stan Hoeppner]

On 1/12/2014 7:55 AM, Martin K. Petersen wrote:
>>>>>> "Chris" == Chris Murphy <lists@colorremedies.com> writes:
> 
> Chris> Huh. Two more cases. All three involve USB enclosures. Bug or
> Chris> feature?  
> 
> Feature.
> 
> Chris> Is it possible the enclosure's bridge chipset is disabling the
> Chris> drive's 512-byte emulation?
> 
> There's nothing to disable. If the USB-SATA bridge exposes 4K logical
> blocks to the host all accesses will inevitably be aligned multiples of
> 4K. All the bridge needs to do is adjust LBA and transfer length. Not
> unlike how we handle 1/2/4Kn in the Linux SCSI disk driver given that
> the block layer always uses 512-byte sectors.
> 
> The two 4Kn USB drives I have both use 512e drives internally:
> 
> # sg_readcap -l /dev/sdd | grep Logical
>    Logical block length=4096 bytes
>    Logical blocks per physical block exponent=0
> # hdparm -I /dev/sdd | grep Sector 
>         Logical  Sector size:                   512 bytes
>         Physical Sector size:                  4096 bytes
>         Logical Sector-0 offset:                  0 bytes
> 
> It is conceivable that there are other USB drives out there that
> actually use 4Kn drives inside but I doubt it. All the 4Kn SATA drives I
> have in the lab are engineering samples...

The user reported 4096B logical sector size with the drive in the USB
enclosure.  He then directly connected to a mobo SATA port and saw 512B
logical sector size.

It seems pretty cut and dried that his USB-SATA bridge firmware was
incorrectly passing the 4096B physical sector size of a 512e drive, as
the logical sector size, to the host.

While this isn't the expected behavior, if the host OS can deal with
4096B sectors, as Linux can, it seems there may actually be some
advantage to this, as it would prevent 512B/RMW misalignment if
partitioning the drive.  As always, if one directly formats the drive
with a filesystem it makes no difference what sector size is reported.

-- 
Stan