Re: FAT and Stores

[Roland McGrath]

> > 512 is The Size.
> 
> Another arbitrary limitation.  Let's put it on the TODO list.

It would be reasonable to remove this limitation from the kernel,
i.e. expose whatever the driver can do.  (I'm not sure it's worth bothering
with that one way or the other before a total overhaul of the device
interfaces.)  I think pretty much everything from the devices back through
storeio can cope with varying record sizes.  If you use --no-cache (i.e. a
BSD-style block device) then user-level must cope with the natural block
size.  Without --no-cache storeio will do buffering as needed to match a
larger natural block size.  But because of the traditional limitations,
there are probably no actual devices that report larger block sizes.

It is indeed an arbitrary limitation in fatfs that it cannot cope with a
store whose block size is greater than 512.  I suspect that our other
filesystems also have the same limitation, i.e. that the store block size
must be a power of two smaller than the filesystem's block size.  
But since disk stores have block size 512, file stores have block size 1,
and the filesystem block sizes are typically 1k or 4k, it has not come up.

Note that the actual problem is not the interface limitation per se, but is
just a bug.  It reported a 1k record size for the floppy, but floppies are
in fact addressable in 512-byte blocks.  I think the gnumach glue code for
Linux devices is not handling the floppy driver properly.  The floppy
drivers use different parts of the Linux device infrastructure than the
disk drivers.  The gnumach linux/glue code falls back to BLOCK_SIZE (1k)
when it doesn't find what it normally finds for disks.  It needs to get the
actual info from the floppy driver, and if there is any falling back to a
default that default should be 512.

I suspect that this already works right in oskit-mach (if one were able to
boot it :-) because the oskit is responsible for the device glue there.  If
we fix the gnumach handling of the floppy driver, I see no reason not to
make it (for both DEV_GET_RECORDS and DEV_GET_SIZE too) expose the real
block size.  Note that since 512 is hard-wired now, there is presumably
someplace else that hard-wires 512 as how to interpret the record numbers
in the i/o calls, that would need to be changed accordingly.

> I'm back, obviously.  it was great fun in Poland.

Glad to hear it.  Sorry to hear it sounds like Bordeaux fell through (at
least for the non-Europeans who needed the sponsored travel).  I no longer
feel like such a lame ass myself for not planning to go (a social trip had
already been scheduled first), but it's a shame that the big meeting of the
Hurd hackers won't take place as expected.