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: Tue, 13 Dec 2005 19:05:03 -0600 Message-ID: From: "Loh, Joe" To: Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id jBEFpFdf018595 We downloaded cygwin-inst-20051213.tar.bz2 and implemented the solution recommended below. So far, our cursory testing indicates that we are able to do unbuffered read. However, we are not seeing any "bug" that was referenced here. What is the "bug" that is being referenced here? Here's the read from the strace showing that the read did what we ask for, which is 512 bytes. 57 222458 [unknown (0x940)] lightning 3480 readv: readv (3, 0x10EED60, 1) blocking, sigcatchers 7 51 222509 [unknown (0x940)] lightning 3480 readv: no need to call ready_for_read 132 222641 [unknown (0x940)] lightning 3480 fhandler_dev_floppy::read_file: 1 (err 0) = ReadFile (1580, 268575744, to_read 512, read 512, 0) 59 222700 [unknown (0x940)] lightning 3480 fhandler_base::read: returning 512, binary mode 52 222752 [unknown (0x940)] lightning 3480 readv: 512 = readv (3, 0x10EED60, 1), errno 0 Thanks, Joe -----Original Message----- From: Corinna Vinschen [mailto:corinna-cygwin AT cygwin DOT com] Sent: Thursday, December 08, 2005 4:57 AM To: cygwin AT cygwin DOT com Subject: Re: Error reported dd'ing close of end of block device with skip On Dec 7 19:35, Corinna Vinschen wrote: > 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. I just added another requirement, that rd.rd_parm must be either 0, 1, or a multiple of 512. Other sizes for buffers don't make much sense. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- 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/