From owner-freebsd-bugs Thu May 11 19:13:30 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA24130 for bugs-outgoing; Thu, 11 May 1995 19:13:30 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA24120 for ; Thu, 11 May 1995 19:13:25 -0700 Received: from ast.com by relay3.UU.NET with SMTP id QQypim27824; Thu, 11 May 1995 22:13:22 -0400 Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA16767 (5.67b/IDA-1.5 for uunet!FreeBSD.org!freebsd-bugs); Thu, 11 May 1995 19:13:29 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Thu, 11 May 95 21:10 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #18) id m0s9k98-0004vxC; Thu, 11 May 95 21:08 CDT Message-Id: Date: Thu, 11 May 95 21:08 CDT To: rgrimes@gndrsh.aac.dev.com, freebsd-bugs@FreeBSD.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Thu May 11 1995, 21:08:05 CDT Subject: Re: problem for reading old CD-ROM Sender: bugs-owner@FreeBSD.org Precedence: bulk [1]I am not sure, I need to go check my iso 9660 spec, but it seems to me [1]that 512 byte logical blocks are a violation of of the spec. Changing [1]the cd9660 code to read non-conformat cd-roms, IMHO, is an ugly hack [1]at best. ISO 9660 6.1.2 (Page 3 of the standard) says: "The sectors of a volume shall be organized into Logical Sectors. Each Logical Sector shall consist of a number of bytes equal to 2048 or 2^n, whichever is larger, where n is the largest integer such that s^n is less than, or equal to, the number of bytes in the Data Field of any sector recorded on the volume." And more to the point of the question at hand: (also from 6.1.2) "If the number of bytes of the Data Field of each sector recorded on the volume is less than 2,048, a Logical Sector shall comprise more than one sector, and the set of the Physical Addresses of its constituent sectors shall form a consecutive ascending sequence. The data of the Logical Sector shall be recorded in the Data Fields of its constituent sectors." So, ISO9660 does allow you to use smaller blocks (say 512 or even 256 bytes) to make up 2048 byte ISO 9660 Logical Sectors. BUT, 512 byte blocks on CDs are not compliant with any Red, Orange (Part II CD-WO), Yellow, Green, (including Kodak Variants), Blue and probably not allowed by the White book either. In CDs, a block is "a unity of 2352 bytes as described in the Yellow Book, (page 100)" - 1.4.1 CD-WO description. Of that 2352 bytes, 2048 is considered to be the Data Area for nearly all non-audio formats on CD. The ISO allowance for non-2048 byte sectors is to allow the 9660 format to exist on other types of media, such as hard disks, Magneto-Optical media, Minidisc, etc. But the Sony/Philips CD standard do not allow non-2048 byte data sectors. [1]Changing block device code to do unaligned block transfers is even [1]worse :-(. Agreed. In fact the ISO specification is quite clear that you must always read and write (during mastering) in 2048 byte Logical Sectors. No fractional reads or writes, even on non-2048 byte data. The entire directory and path look-up strategy relies on this. Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983