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...) and - 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. Eric ------------------------------------------------------------------------------ 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! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
