From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: HDIO_DRIVE_CMD and hdparm Date: Thu, 10 May 2007 09:20:18 -0400 Message-ID: <46431C12.1030207@rtr.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org To: Geert Uytterhoeven Cc: Linux Kernel Development , linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org List-Id: linux-ide@vger.kernel.org Geert Uytterhoeven wrote: > Hi, > > `hdparm -t' uses HDIO_DRIVE_CMD(null) to flush the disk's buffer. More correctly, that command is supposed to act like an I/O queue "barrier" operation, not returning from the syscall until everything queued in front of it has been issued/completed. I believe that only the original IDE driver actually implements it, though. And hdparm-7.4 (not released yet) will no longer complain about ENOTTY. Note that current versions of hdparm use SG_IO/ATA_16 (SAT) for nearly everything now, only falling back to the older ioctl's for drivers which reject the SAT attempt. I'd love to find a USB drive enclosure that supports SAT. Anyone know of one? And does the USB storage layer actually pass the ATA_16 packets to the device? Cheers