> 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.
This depends on whether rounding (when converting the specification of a
number of directory entries to a number of sectors) is required, and if
so, whether the rounding that is necessary is more than the most rounding
possible for the smaller sector size. Usually, rounding is not necessary
at all because as I noted formatting software wastes none of the space in
the last sector.
> 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.
Right.
> 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.
Yes.
>> 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.
No, you forgot that if too many root directory entries are unused/wasted
in the last sector, then the transformation driver needs to adjust the
"root entries" BPB field. Doing that is possible and will render the file
system accessible, but an incompatibility arises if any of those
previously unused/wasted entries are used, as they will remain
inaccessible to drivers natively accessing the FS. Usually, however, a
specific program could trivially modify/fix the FS to use all entries of
the last sector to prepare it for usage with the transformation driver.
> 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.
Yes.
> DOS must be aware that I/O of N sectors will be larger
> than usual if sectors are larger (64 kB and DMA limits).
Interesting. This might raise some issues. However, I think the driver
could be written to handle all of that properly.
> 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...
>[...]
>- 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.
No, as I mentioned, even if things are misaligned, as long as the cluster
size is large enough all "moving around"/translation seems rather trivial.
If I am not mistaken, you'd only have to do some simple calculations on
things like number of reserved sectors, FAT size, and root size, and then
(if it is a runtime transformation driver which is to translate the FS to
DOS on-the-fly) translate sector numbers from the "virtual data area",
"virtual root area", etc (addressing scheme seen by DOS) to the "real data
area", "real root area", etc (addressing scheme on the block device) and
vice versa.
Here's some example C-like pseudo-code for the translation from "virtual"
sector number to a "real" one, which for now handles only a simplified
case where the FS uses a single FAT:
sec translate_virtual_to_real(sec virtSec) {
sec realSec = virtSec;
if (virtSec <= virtLastResSec)
;
else if (virtSec <= virtLastFATSec)
realSec += -virtFirstFATSec + realFirstFatSec;
else if (virtSec <= virtLastRootSec)
realSec += -virtFirstRootSec + realFirstRootSec;
else
realSec += -virtFirstDataSec + realFirstDataSec;
return realSec;
}
(To handle multiple FATs, each FAT would have to be differentiated into
its own "area" for the translation. To handle even unusual numbers of FATs
(> 2), this would have to be implemented dynamically.)
The referenced variables (except virtSec and realSec) are here assumed to
be global variables that are initialised as the FS is prepared for
translation.
In a misaligned FS (which necessitates the additional translation in the
first place), virtFirstFATSec for example might be different from
realFirstFATSec. To extend the example, take a typical FAT16 FS that
utilises 512 B sectors; the realFirstFATSec (corresponding to the number
of reserved (512 B) sectors) might be simply 1. If the driver were to
translate that FS to one with 4 KiB sectors, it would set virtFirstFATSec
to 8, which is the equivalent address of the second 4 KiB sector shown to
the OS.
In other words, in the original FS, the first FAT starts at a 512 byte
offset from the beginning, but in the translated view it needs to start on
a 4 KiB boundary. The translation would thus show the first FAT starting
at a 4096 byte offset from the beginning (hence, 8 512 B sectors).
In a misaligned FS, some areas would then be purely emulated and not
correspond to actual data on the disk. In the previous example, the last
3.5 KiB of the virtual first reserved (boot) sector would be such an area,
as the actual reserved sectors area would only consist of the single 512 B
sector. All writes to the shown (4 KiB) boot sector could simply discard
this upper 3.5 KiB, and all reads from there could then turn up all zeros
in this upper 3.5 KiB.
I hope you get the idea now. That was a lot of words words words.
> 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 ;-)
As I mentioned previously, it could be useful to access file systems with
sector sizes < 512 B in a DOS that doesn't support such sector sizes. The
FDK appears to almost or entirely support such smaller sectors properly
already though. (They are much easier to implement than larger sectors,
requiring no special larger buffers.)
regards,
C. Masloch
------------------------------------------------------------------------------
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
