Re: Resizing FAT partitions

Ah, now that I think about it more and I've read that part of fatgen103.docx
over a few times, I think I understand. The formulas calculate the size of
the FAT based on any volume size given (defined by number of sectors in the
partition). This number won't necessarily always be an exact multiple of the
size of the sectors, so there could be sectors left over that don't form a
full cluster, and are thus part of the volume, but unused.

One question I do have though is if there is something I should know when
determining the max amount of space to partition on a given drive. Say a
drive is exactly 1000 MB total. Do I have to leave unpartitioned space or
can I use all of the space available on the drive (everything not being used
by the MBR and reserved portion at the beginning of the drive)?

Thanks again for your help!

Regards,
David

"David Craig" wrote:

The fatgen103.docx has specific formulas for computing those variables for
each type of FAT with a fixed table used for floppies. Follow the formulas
and don't try to improve them as those are the MS approved way that can
cause an additional unused FAT block to be allocated. You have to read that
doc several times before you can catch all the nuances involved. Also
having fastfat.sys source available will help with understanding the CRCs
used in LFNs. Look at each sector as defined in the doc and realize that
the partition boot sectors (one for FAT16) and the FATs and the root
directory (fixed size) come before the clustering counts. While the doc
says that the first cluster is 2, that does not mean you can try and use
either zero or one and obtain anything useful. You locate the FATs and root
directory from the information in the BPB. You get the total sectors by
adding all those reserved areas to the number of sectors required to hold
the number of clusters specified.

"David K." <DavidK@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F0A5EE28-3C75-48DD-8A9A-79388A4B1730@xxxxxxxxxxxxxxxx
Ok, one last thing I've come across. I've been using WinHex to closely
examine the MBR/partition tables and the FAT partition of a drive I
already
have. I'm getting quite comfortable with the layout and understand
everything I need to change but there is one oddity I've encountered.

For this FAT16 partition of ~1GB, the 32-bit number of sectors in
partition
field (BPB_TotSec32) contains the value "81 D6 1D 00" which is equivalent
to
1955457 sectors. There are 512 bytes per sector and 32 sectors per
cluster.

This SHOULD mean that if I divide the total number of sectors by the
number
of sectors per clusters, I will get a whole number, since my understanding
is
that the partition is aligned to end at the end of a cluster. However, if
you divide 1955457 / 32, you will realize that it is one sector "off".
That
is to say, if the total number of sectors was 1955456, it would be evenly
divisible. Am I missing something here?

I'm wanting to know this because I will need to be able to calculate the
number of clusters/sectors to allocate to a partition given the size of a
certain disk. Any help you can lend is appreciated!!

Thanks,

David K.

"David Craig" wrote:

1. From the document, it appears it should work. I would test some of
those volumes with various versions of Windows and third-party tools to
see
if they dislike having FATs too large for the volume.
2. Another possibility in your copy routines is that with USB keys, they
are treated as removable drives which could inhibit caching of the system
areas as much as would be optimal for your task. Maybe forcing them to
be
optimized for quick access instead of for removability would improve the
performance of xcopy. You would want to have your utility to grab
exclusive
access to the volumes after the xcopy completed to ensure everything has
been flushed.


"David K." <DavidK@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:19BE7375-C795-45A4-B24D-C7FA87CC9591@xxxxxxxxxxxxxxxx
Thanks for the comments JJ, you make some good points.

Since this will be done on-the-fly, with copying performance being key,
renumbering all the cluster references in the FAT or otherwise having
to
rearrange the data on the drive by reallocating clusters is not
something
I
am going to be dealing with. Instead, before the drive begins copying,
my
understanding is that I can look through the FAT table that maps the
clusters
on the partition, and find the last cluster that is mapped. Using that
cluster number, I can calculate how small the partition can be made
without
reallocating data clusters. If the drive is fragmented heavily, users
will
not be able to copy to such small drives. If it has just been
defragmented,
10GB of data from a 150GB partition should fit into a 20GB partition
without
a problem.

As for resizing the FAT itself, my understanding was that the FAT uses
cluster numbers that are relevant to the end of the FAT area itself.
Therefore, if the area reserved for the FAT is made larger, these
cluster
numbers will still all be valid entries provided that the appropriate
values
in the BS/BPB are updated (BPB_FatSz16/BPB_FatSz32). Am I not
understanding
this correctly?

Also, the FAT size would only NEED to be changed if I was making the
partition larger. If the partition is being made smaller, the size of
the
FAT itself doesn't have to be changed even if it no longer needs to use
as
many sectors as it currently is. The unused portion will just be lost
drive
space, which seeing as it is a fairly negligible amount of space, is
not
going to be a problem to most users.

My understanding is that although I will be reducing the size of the
partition and the number of clusters will be changed, this won't affect
the
numbers of any of the clusters. For instance, imagine a partition that
spans
100 clusters for the data area of the FAT (which is of course a
ridiculously
small number). If the 56th cluster is the last one being used then I
can
resize the partition to only have a total of 57 clusters. This should
not
change the index of any of the clusters. Once again, I may be totally
wrong
on this, and if that's the case then please let me know where I am
going
wrong.

Thanks again for your time and patience!

David K.

"JJ" wrote:

David K. wrote:
David, thank you for your quick response.

[snip]

So, after all that explanation, my question I think is somewhat
straightforward. Can resizing a partition really be as simple as
just
changing the appropriate values in the partition table and the
BS/BPB
provided I am not modifying the cluster size?

Thanks again!!

David

When partition size changes, so does the total number of clusters.
Since
it also affects cluster numbers, these items will need to be adjusted
also:
1. FAT size
2. FAT entries
3. Directory entries

Both #2 and #3 are necessary for the following cases:
- Cluster size is changed.
- Partition is shrinked small enough where allocated clusters need to
be
relocated.

Although FAT is a quite simple file-system, resizing one can be a
complicated process, especially with large number of clusters. A
volume
with fragmented files/directories will also make things more
complicated.







.

Relevant Pages

  • Were OT now... Re: Shared/moved Font Folder
    ... formatted a 200 meg FAT partition as a primary. ... When I did a check (from DOS) of that drive with Partition Magic it ... howerver, re-letter the drives. ...
    (microsoft.public.win2000.file_system)
  • Were OT now... Re: Shared/moved Font Folder
    ... formatted a 200 meg FAT partition as a primary. ... When I did a check (from DOS) of that drive with Partition Magic it ... howerver, re-letter the drives. ...
    (microsoft.public.win2000.registry)
  • Re: 2 large hard drive questions
    ... 4K cluster size is fine for windows partition. ... would have on these big drives. ... I noticed that Disk Manager in Windows XP SP2 reports the disk as ...
    (microsoft.public.windowsxp.hardware)
  • Re: Resizing FAT partitions
    ... examine the MBR/partition tables and the FAT partition of a drive I already ... of sectors per clusters, I will get a whole number, since my understanding is ... that the partition is aligned to end at the end of a cluster. ... not be able to copy to such small drives. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Computer Backup
    ... External USB hard drives typically are already formatted and ready ... FAT 32 so that the whole drive is usable right out of the box.. ... The total partition size that FAT 32 can handle is 512 GB for Windows ... 98/ME because of the limitations of the fdisk program. ...
    (rec.outdoors.rv-travel)
Loading