Re: NeXT formatted disks (was Re: next68k port status?)

Brian Willoughby <[email protected]> writes:

> [  The biggest problem is that disks are addressed by sector number, which
> [  means that the kernel and the disk have to agree on the sector size for
> [  things to work.  For example, a kernel that assumes .5K blocks would
> [  expect that reading 1K starting with block 0 returns the same data as
> [  reading .5K at block 0 and .5K at block 1; a disk with 1K sectors will
> [  return rather different data for the second half-K when accessed thus.
> 
> It's too bad we don't have the NeXT kernel sources to examine, because the  
> NeXTSTEP kernel sure seems readily able to adjust to the block size on a  
> per-device basis.  You can have multiple drives attached and accessible at the  
> same time, some with .5K and some with 1K (not to mention 2K CD-ROM, but there  
> might be some sleight-of-hand going on there).  I understand what you're  
> saying, but the NeXT code does not seem to be hard-coded in this respect.   
> However, if the NetBSD code is hard-coded, then it might take a significant  
> revision to support varying blocks/sector.

We don't need NeXT code for this.  Darwin can also handle it, and its
sources are available, although we probably don't want to solve it
exactly the same way as Darwin.
> 
> One thing I have not tested is devices with a block size greater than the  
> filesystem sector size.  Once upon a time, before CD/R was prevalent, I wanted  
> to make a NeXT CD-ROM.  I was told to format a SCSI hard drive with 2K blocks  
> and use newfs to create a filesystem with 2K sectors.  Then, it would be easy  
> enough to do a block copy from the SCSI drive to a CD.  This is still a block  
> size equals sector size setup.  I'm wondering if the NeXT kernel would be happy  
> reading a 1K sector filesystem from a 2K block device.  Somehow I really doubt  
> it.

Probably not.  It would not be hard to make NetBSD support filesystems
where the filesystem sector size, i.e. 2^(fs_fshift - fs_fsbtodb), is
a multiple of the device sector size.  Other possibilities, such as
making NetBSD support filesystems with a sector size smaller or a
non-multiple of the the device sector size, are significantly more
difficult.

Furthermore, having NetBSD support device sector sizes other than
DEV_BSIZE (which is currently 512) is a larger and more difficult
project, and there are several PRs and tech-kern discussions on this
topic.

Anyway, if I get some time for this, I will first work on fixing the
Apple UFS support and then maybe the NeXT filesystem support.  I will
probably not look at the more difficult device DEV_BSIZE issue in my
volunteer time.

Darrin

> 
> Brian Willoughby
> Sound Consulting