Re: Resizing FAT partitions

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: Resizing FAT partitions
    ... each type of FAT with a fixed table used for floppies. ... You get the total sectors by ... the number of clusters specified. ... examine the MBR/partition tables and the FAT partition of a drive I ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Partition/Cluster Size/Wasted Space
    ... partitioning drives, the larger the partition, the larger the clusters, ... unit can change as the total disk or partition size goes up. ... the clusters are laid out in 4KB...so the 5KB file must use two ... Modern file systems do a lot to alleviate this issue, ...
    (alt.sys.pc-clone.dell)
  • Re: Partition/Cluster Size/Wasted Space
    ... clusters, ... size of this smallest unit can change as the total disk or partition ... Modern file systems do a lot to alleviate this issue, ... easier to navigate with fewer logical drives than half the alphabet ...
    (alt.sys.pc-clone.dell)
Loading