You're only going to store one file (pagefile.sys) on this disk/partition, so storage lost to half-empty clusters isn't an issue. At most, you'll lose n-1 bytes, where n is the size of the cluster, plus the overhead of the file system and the directory entry. (Storage loss per file for a typical file system is normally n/2.)
Fragmentation will remain an issue, as the data written to the page file becomes fragmented over time, whether or not the page file itself is fragmented.
For best performance, you should use NTFS with 64K clusters. FAT partition performance degrades quickly with size. (Side note: never convert a FAT partion to NTFS, as the partition will always use 512 bytes clusters. Very poor performance.)
The size of the page file should be based on the memory requirements of your applications and is usually something like max(total, largest_allocated) - physical + 12 (i.e. the maximum of either the total amount of memory used by all applications or the largest block of memory allocated by a single application minus the amount of physical memory in the system plus 12).
If you intend to produce and debug system dumps, you must have a page file on your system disk. You'll get slightly better performance by using a separate partition. You'll only see increased performance on a separate ATA disk if you place the disk on its own channel.
Quick note. A page file is about allowing you to do more with less. A properly written application with accurate memory requirements souldn't suffer performance problems just because a page file exists on the system. Setting aside physical memory as a RAM disk for storing the page file just doesn't make sense. If you don't need the extra memory, remove it. If you don't need the page file, don't create one (or just use the minimum required).
And from the perspective of the FAT file system, 1GB is, as Mike Meyers would say, "Friggin' huge!"
Trev
