So, suppose my friend used RMPrep or some other tool to partition, format, and create a bootable Linux Live USB flash drive for example. Say it is FAT32. I noticed if you reformat under Windows sometimes, it asks if you want to revert back to the default allocation unit.

So what would be a way or a tool to figure out the current allocation unit for a FAT32 volume, or even NTFS.

*****

Furthermore, suppose he clones a 2Gb stick and I restore it to a 4Gb stick or vice versa. Now the stick thinks it is smaller or larger than it really is as the case may be. Obviously the solution is to not use this method, but to note what RMPrep settings were used, maybe zip up the contents for the UFD, and share it that way.

However, I got curious to see if I could use something like an old partition editor, like PTEDIT32 (or a hex/disk editor), to rework the partition table so it was the correct size (roughly) for the particular flash drive. I did change some values but didn't have much luck.

I suppose the CHS values used will depend on which options are used in RMPrep, obviously, but I am curious how to properly interpret the values and convert them so they are correct for the disk size. So, obviously there are some basics to CHS I don't have down pat.

I should ask, on a UFD, using RMPrep, and picking, for example FAT32 for the type, how does it do the work of picking the CHS values?

Or even using Windows to format it... is this different than on a hard disk, it's a super-floppy right?

Or, maybe this (the partition table) isn't what tells XP the size of the flash drive. I did notice tools like RMPRep often see the true size, but XP can't use the true size because of what info?

So, suppose my friend used RMPrep or some other tool to partition, format, and create a bootable Linux Live USB flash drive for example. Say it is FAT32. I noticed if you reformat under Windows sometimes, it asks if you want to revert back to the default allocation unit.

So what would be a way or a tool to figure out the current allocation unit for a FAT32 volume, or even NTFS.

*****

Furthermore, suppose he clones a 2Gb stick and I restore it to a 4Gb stick or vice versa. Now the stick thinks it is smaller or larger than it really is as the case may be. Obviously the solution is to not use this method, but to note what RMPrep settings were used, maybe zip up the contents for the UFD, and share it that way.

However, I got curious to see if I could use something like an old partition editor, like PTEDIT32 (or a hex/disk editor), to rework the partition table so it was the correct size (roughly) for the particular flash drive. I did change some values but didn't have much luck.

I suppose the CHS values used will depend on which options are used in RMPrep, obviously, but I am curious how to properly interpret the values and convert them so they are correct for the disk size. So, obviously there are some basics to CHS I don't have down pat.

I should ask, on a UFD, using RMPrep, and picking, for example FAT32 for the type, how does it do the work of picking the CHS values?

Or even using Windows to format it... is this different than on a hard disk, it's a super-floppy right?

Or, maybe this (the partition table) isn't what tells XP the size of the flash drive. I did notice tools like RMPRep often see the true size, but XP can't use the true size because of what info?

thanks...

1. What about chkdsk ?

C:\Users\Administrator>chkdsk k:
The type of the file system is FAT32.
Volume Hirens created 01/01/2000 00:00
Volume Serial Number is 65C7-5E79
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problems.
8,080,896 KB total disk space.
68 KB in 10 folders.
512,568 KB in 452 files.
7,568,256 KB are available.
4,096 bytes in each allocation unit.
2,020,224 total allocation units on disk.
1,892,064 allocation units available on disk.

2. For the rest of the Q's I think you need to read up on the MBR, partition tables and the FAT filesystem - I suggest Starman's info here.For FAT data structure see here. No doubt others (Wonko?) can point you to better sources.You cannot just alter the MBR partition table, you have to also also the values in the FAT PBR tables as well which is not trivial!

As for RMPrep, when formatting FAT16/32 it does not use the OS at all. It simply chooses what CHS geometry to use based on the user settings.

If you use the latest version of RMPrep, it will display the decoded values for a valid MBR partion table or a valid PBR (partition boot record - e.g. sector 63) which may be useful in your investigations. You can also use the DiskDoctor utility (Ctrl-D) to examine disk structure (but make sure you select a USB drive if you are going to try writing to a disk!).

C:\Users\Administrator>chkdsk k:
The type of the file system is FAT32.
Volume Hirens created 01/01/2000 00:00
Volume Serial Number is 65C7-5E79
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problems.
8,080,896 KB total disk space.
68 KB in 10 folders.
512,568 KB in 452 files.
7,568,256 KB are available.
4,096 bytes in each allocation unit.
2,020,224 total allocation units on disk.
1,892,064 allocation units available on disk.

Oh, yes chkdsk of course. I wonder if it can be found without actually running the disk check? But thanks for reminding me.

2. For the rest of the Q's I think you need to read up on the MBR, partition tables and the FAT filesystem - I suggest Starman's info here.For FAT data structure see here. No doubt others (Wonko?) can point you to better sources.You cannot just alter the MBR partition table, you have to also also the values in the FAT PBR tables as well which is not trivial!

As for RMPrep, when formatting FAT16/32 it does not use the OS at all. It simply chooses what CHS geometry to use based on the user settings.

If you use the latest version of RMPrep, it will display the decoded values for a valid MBR partion table or a valid PBR (partition boot record - e.g. sector 63) which may be useful in your investigations. You can also use the DiskDoctor utility (Ctrl-D) to examine disk structure (but make sure you select a USB drive if you are going to try writing to a disk!).

Yes, I have read the Starman's info, but it has been a while. I need to review, absorb, and work some CHS calculations to get it down.

I was wondering if there is any difference when it comes to a UFD regarding partitioning and formatting than from a HDD?

Ow, come on.
That's the filesystem allocation units, they are "declared" in the BPB of the boot sector.
Just open the bootsector in disk editor (as an example Tiny hexer) and have a look at the fields "byte per sector" (which 99.99% will be 0200 aka 512) and "sectors per cluster" and multiply them.
Of course you can run a tiny batch to get this info, see if you can do something with what was posted under "Spring effect graphics" here:http://reboot.pro/13466/

@steve6375
For you, maybe an idea to introduce alignment in FAT32 filesystems on stick:http://www.msfn.org/...n-its-clusters/
(by introducing a larger number of hidden sectors, NOT by moving the partition offset)

@steve6375For you, maybe an idea to introduce alignment in FAT32 filesystems on stick:http://www.msfn.org/...n-its-clusters/(by introducing a larger number of hidden sectors, NOT by moving the partition offset)

What offset do you suggest? Flash memory is divided into pages when erasing for a read/erase/write cycle depending on the size of the chips used and their design. Any flash drive could use a 64k,128k,256k, 512k or larger erase block size? I can see that new 4k Enhanced formet HDDs would benefit from 4K aligned clusters as the 'write' block size is 4k, but why would a flash drive with a 128k erase block size benefit much at all?

Ow, come on.That's the filesystem allocation units, they are "declared" in the BPB of the boot sector.Just open the bootsector in disk editor (as an example Tiny hexer) and have a look at the fields "byte per sector" (which 99.99% will be 0200 aka 512) and "sectors per cluster" and multiply them.Of course you can run a tiny batch to get this info, see if you can do something with what was posted under "Spring effect graphics" here:http://reboot.pro/13466/

Sweet, thanks for the tip! (I like the graphs too). Yup, don't think I ever saw anything but 512 bytes per sector.

What offset do you suggest? Flash memory is divided into pages when erasing for a read/erase/write cycle depending on the size of the chips used and their design. Any flash drive could use a 64k,128k,256k, 512k or larger erase block size? I can see that new 4k Enhanced formet HDDs would benefit from 4K aligned clusters as the 'write' block size is 4k, but why would a flash drive with a 128k erase block size benefit much at all?

That is another thing.The point is about aligning the offset to the filesystem cluster size or multiple thereof.Though it has IMNSHO not hat much an effect on good hard disks, if not for "particular" uses, compare with:http://reboot.pro/9897/(post #5)on sticks there is some difference, see this (which is a bout a CF card which behaves AFAIK very like any other flash device, including USB sticks):http://www.msfn.org/...ers/page__st__9In other words, independently from the device page file, having filesystem structures aligned to an "even"" number of sectors may help.The value that might give better results should be found by experiment and may depend on the single device ;ph34r:.BTW, under XP there is this "added" issue:http://www.msfn.org/...d-on-usb-stick/which is yet another thing, the "dumbified" FAT32 driver of XP.