Hi Chris,

>>> NOTE: Transformation of sector sizes is easiest in FAT32.
>>> Other FAT sizes may take more effort.

> You're probably referring to the root directory alignment handling,  
> which of course is not needed in FAT32 as its root directory is not
> in a specifically reserved area.

Correct - in FAT32, the root directory is just a group of data
clusters. In FAT12 and FAT16, you specify the size of the root
directory instead. However, the size is specified in entries,
not sectors, so maybe you are right: FAT12 / FAT16 COULD be as
EASY to transform as FAT32. Another aspect is that FAT32 always
has multiple special sectors (boot, fsinfo...) before the FAT
starts. For FAT12 / FAT16 other numbers than 1 "reserved" boot
sector are UNUSUAL but SHOULD be handled okay by our kernel.

Similarily, having more sectors per FAT than strictly needed
(because FATs start and end at multiples of 4 kB even if you
show virtual 512 byte sectors) is UNUSUAL for ALL FAT sizes
(12, 16, 28 / 32) but SHOULD be supported by our kernel: For
partition resizing tools, it is easiest to keep FATs and dir
data unchanged when shrinking a disk, so your FATs waste some
space for info on clusters which are no longer are available.

> As I noted in our (Eric) previous correspondence, the special case where  
> some rounding is required (which might imply an incompatibility) doesn't  
> usually occur (as formatting software usually leaves no unused directory  
> entries in the last sector).

See above: You can always transform a 4096 byte per sector
filesystem into one with 8 times more 512 byte sectors, as
long as nothing overflows, but the transformed view LOOKS
as if you wasted some space in the boot, root or FAT area,
e.g. 24 kB per FAT instead of 23 kB when 22.9 are in use.

Overflow can happen in "size of filesystem" and "size of
cluster", because a cluster must have at most 128 sectors
(64 recommended, 256 possible with special DOS versions)
and a FAT disk must have at most 2^32 sectors and if you
have bigger sectors, you COULD have bigger clusters and
filesystems than would be possible with smaller sectors.

DOS must be aware that I/O of N sectors will be larger
than usual if sectors are larger (64 kB and DMA limits).

The INVERSE incompatibility is that you cannot transform a
FAT filesystem with really 512 bytes per sector and 23 kB
per FAT into something that you could store on a disk that
has 4096 bytes per sector easily: You would have to move
things around because you will be forced to round up FAT
sizes to multiples of the true, larger, sector size...

> Another additional note, as I went thinking ... Only cluster  
> values are stored in the FS (think FAT contents, FSINFO, and "start  
> cluster" fields of directory entries) apart from what is in the *BPB

Exactly. This is why you can transform sector sizes in BOTH
directions, virtual being a multiple or fraction of real iff:

- no BPB field overflows (smaller virtual than real sectors)
- no calculation overflows (same context, fails if you have
  a partition larger than 2^32 virtual sectors or a cluster
  size corresponding to too many small virtual sectors...)


- everything can be expressed in multiples of real sectors
  (fails if you copy a small-sector filesystem to a big-
  sector disk unless FATs, root and clusters all happen to
  be multiples of the big sector size big already anyway)

The latter means that if your disk has SMALL sectors, you
have to be lucky with alignment and your clusters must be
big enough if you want to use it as virtual BIG sectors.

You will need additional checks to check for alignment but
you are right that transformation works in both directions
(bigger/smaller sectors) as far as the general idea goes.

However, using a small sector disk to simulate a disk with
big sectors feels sort of academic. It might be useful as
a way to test big-sector compatibility of a DOS kernel ;-)

Another use could be disk-copying a partition from a small-
sector disk to a big-sector disk. As said, it only works if
you are lucky with alignment of things.

I think I prefer USING and COPYING big-sector partitions
in small-sector DOS kernels or to small-sector disks, as
this is 1. the type of kernel I like to use and 2. easier
and almost always possible - unlike the other direction.


Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
Freedos-user mailing list

Reply via email to