The following reply was made to PR kern/7668; it has been noted by GNATS.

From: Reinoud Zandijk <reinoud@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/7668
Date: Thu, 9 Nov 2006 02:49:38 +0100

 Hi folks, hi Bill :)
 
 The problem is still here today. I've investigated FFS1 and FFS2 on CD-MRW 
 media. This media is 2048 bytes/sector and behaves like a `normal' block 
 device.
 
 First of all, newfs/mkfs.c and fsck_ffs/utilities.c only need minor 
 patching since with the inclusion of APPLE_UFS support it will try to read 
 a structure of 1024 bytes, i.e. smaller than sector size. Fixed easily with 
 a read buffer and a memcpy.
 
 It then is able to format the CD-MRW. It also fsck's fine and dumpfs works 
 too.
 
 However, things go wrong when you try to mount the fs. The kernel uses 
 SBLOCKSEARCH[i]/sectorsize for the super block search. This calculation 
 results in different superblock location values than the ones 
 newfs/fsck/dumpfs make.
 
 Since the newfs/fsck/dumpfs superblock calculation is dependent on things 
 like fragment size etc. which aparently with `normal' values of fragment 
 sizes and blocksizes are OK. When formatting with sectorsize 2048 and 
 fragment size 2048 things get nasty. Specifying bigger fragment sizes like 
 4096 or 8192 with this sector size shows that the first super block number 
 printed is moving (!)
 
 It would be wise to change the userland tools since the kernel doesn't know 
 about fragmentsize etc. when its reading a superblock since thats recorded 
 in there!!!
 
 I tried a small patch that calculated the same super block number in the 
 newfs but then i bump into bad magic numbers for cylinder group 0 so there 
 is more wrong... maybe i ought to have only changed the superblock 
 calculation and leave the other `magic' numbering in place.
 
 This fix is also important to be able to support > 2Tb discs with 32 bit 
 sector numbers.
 
 With regards,
 
 Reinoud