>>>>> "Stan" == Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
