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

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/7668
Date: Thu, 9 Nov 2006 20:03:20 +0000

 On Thu, Nov 09, 2006 at 01:50:02AM +0000, Reinoud Zandijk wrote:
 >  
 >  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 (!)
 
 The problem to solve here is what is the 'correct' location for these 
 structures.  Just because one set of programs run doesn't mean that the
 data they generate should be considered correct.
 
 My personal opinion is that the on-disk format should not depend on the
 physical block size - although it may be reasonable to disallow
 filesystems where the filesystem block size is smaller that the physical
 sector size.
 
 From what I remember of hacking newfs, this shouldn't cause any
 problems with disks with sectors sizes <= 8k (the size of the superblock).
 
 	David
 
 -- 
 David Laight: david@l8s.co.uk