X-Spam-Check-By: sourceware.org Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Error reported dd'ing close of end of block device with skip Date: Wed, 7 Dec 2005 16:47:12 -0600 Message-ID: From: "Loh, Joe" To: Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id jB7MlMTl028209 >> On Dec 7 11:55, Loh, Joe wrote: >> QUESTION: >> >> Is there a way in Cygwin to do a read of a block device using "C" that >> does not do a read-ahead? We needed to develop an application that >> will issue the exact transfer size to the target device as requested. >> Looking at the strace, it appears that read() less than 61440-bytes >> gets translated to reading 61440 bytes into buffer and then a subset >> of that read is returned to the caller. > > There's a non-portable (only Cygwin) way to set the buffer size after opening a device: > > #include > > struct rdop rd; > > fd = open ("dev/sda", ...); > > rd.rd_op = RDSETBLK; > rd.rd_parm = 0; /* Unbuffered reading */ > rd.rd_parm = 1; /* Unbuffered reading */ > rd.rd_parm = n; /* Buffered reading with buffer size n */ > > ioctl (fd, RDIOCDOP, &rd); > > Note that the ioctl fails if the buffer already contains data, so ioctl should be called before the first > read. Also note that in unbuffered mode the usual Windows blocking rule applies, the length given to read > must be a multiple of 512. > > Sigh, it seems that I introduced a bug into this ioctl also not long ago. > I fixed this in CVS. Recent code will probably not work very well when setting it to unbuffered mode. Please wait for the next developers snapshot. > > > Corinna Thank you ... This will work. Any plans on supporting O_DIRECT flag in open()? We believe this effectively gives unbuffered I/O. Please correct if we are making the wrong assumption. Again. Thank you for the recommendation and we will wait for the next Cygwin Kernel before porting our codes over. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/