Is it possible to create a C: drive with 64K clusters?

umm... this works with Vista and SP2 (not SP1) and i tested and confirmed it working on Win7 (i posted this last year actually)

During Win Install Shift F10:

Diskpart
select disk 0
create partition primary size=35174
create partition primary size=128 (i didnt actually have to put size as that was all that was left anyway)
select partition 1
format fs=ntfs label=Alpha quick unit=64k
assign letter=c
select partition 2
format fs=ntfs label=Omega quick unit=4k
assign letter=d
active
list partition (both Partition 1/2 show up)
list volume (shows my CDROM then shows C: as Alpha -34GB- and D: as Omega -128MB- good to go right! )
exit

this was on my old WD Raptor, I have since upgraded to a bigger drive and used this method again (adjusting size of course for new HDD)

(also i signed up just to reply to this over a month old post... sad isnt it) :/

Thanks Kane for showing me another way to partition the disk, but the problem I have is the Windows 7 installer - it reports an error when the c: partition has 64K clusters.

Have you actually been able to install Windows on such a layout?

Cheers, Eric

Yes this worked for me perfectly, you have to follow those commands exactly pretty much (except the size)

I am very interested in using the 64k block allocation as well. I have two new unformatted WD Velociraptor drives (a 150gb and a 160gb) I want to use the 150 for my C drive (for Windows 7 x64 and other programs) and the 160gb drive for my Flight Simulator only. (will call it F drive..)

I have read in sim forums (and from a knowledgeable administrator) that using a dedicated physical hard drive (and not a partition) for the sim with a format of 64k block allocation (particularly with the WD V-raptor drives) helps alot with faster or more efficient scenery loading. I use up to 100 gigs of scenery alone so I assume much of the individual files are rather large. There is alot of advanced detailed scenery available now so I assume the 64k allocation for F: alone will be a good thing.

However, would also setting the up C drive with Windows 7 x64 and 64k blocks have any added benefit or is "block size matching" between these two non RAID drives even an issue worth hassling with? A caveat here is I will also install several sim related programs on the C drive that will need to reference the other drive (F) while in flight hence my main concern for having both C and F set to the same block sizes.

replied to your PM, hope it gets to you ok :)

Kane, I got your reply but could not PM you back for some reason. It seems this forum doesn't like you to keep messages as my inbox was full with our one exchange. So, if you can, and are willing please send me your regular email in a PM if you dont mind. The pics you saw on my website are 5 outputs/3 video cards/1 PC. --My regular email is also found on the home page of my website.

As far as my sim file sizes go I am having to get that answered from a freind. My PC is awaiting this format based on my/our decision on block size and therefore I have no way to look at files that are not yet installed ! (Im writing from my laptop)

Again, I routinely install 80-100 gigs of data with the typical NTFS 4k blocks as I have never attempted anything aside from stock/default formatting procedures. I had just read a tutorial from a sim forum moderator that specifically recommended formatting your sim specifics drive at 64k. So what I really need to know is would the 100gigs of my typical install far exceed the capacity of my 160gb drive? (if set to 64k?) --- Should I get a 300gig Velociraptor instead?..or is 32k an acceptable compromize for both drives? --I imagine these file sizes for the sim will be completely random from a few kb up to several MB per scenery file. For instance a "pack" of scenery for say Southern California may be 5gigs total but will be comprised of at least a thousand ".BGL" files for instance, which all vary in size. Hope that helps.

Hey,

PM is on its way

Both Vista and 7 'usually' work well with C: drive being 64K clusters, and boy
does it run fast. As others have posted, one needs to be sure to have
a separate 'system boot' partition.. That one MUST BE 4K clusters, or
the boot loader will not work.

As others have said, you can interrupt the windows install, and first format
the future C: partition with NTFS 64K clusters, or use Acronis Disk director
to format with 64k clusters, etc.. and windows7 will install ok and leave
it at 64k. Just don't mess with the boot partition cluster size.

For an after the fact '64k cluster upgrade', assuming you have a 'system boot'
partition, and your C: drive is 4K cluster, you can boot up Acronis Disk Director
or equiv and change it to 64K cluster. Be sure to make a backup before.

More likely than not, your system will not boot after this change. Insert
the win7 install disk, and initiate a startup boot repair.. may take 2 or
three attempts, and then it should work fine.

The reason I said this 'usually' works, is that I have some issues on one
system on an Areca-1221X raid controller (8 drives). It runs ok for
5-60 mins (even setting idle), and then takes a disk hang.

O&O drive LED3, shows C: hanging with pending I/O ... things which don't
need I/O keep working for awhile, and eventually hang also. Need to
reboot to clear. I would take a wild guess that this is paging I/O, since
other partitions are 64k clusters and don't hang. O/S is win7 x64.
Put it back to 4K cluster and it seems to have cleared up.

Of course, it might be an Areca driver issue also. I doubt that 64k cluster
C: drives are officially supported, so we probably don't have a leg to
stand on about griping to someone. In the past, Microsoft has gone
out of their way to make 64k C: drives difficult on XP and Vista.

There also may be some issues on bitlocker encryption and file compression.
From memory, this summer with WIn7 Beta Rc1 or such, with a 64k (cluster)
C: drive, I think bitlocker (drive encryption) still worked, but file compression
did not. If one compressed files (show up as blue), when drive was 4K, and
changed to 64k, then previously compressed files could be seen and
decompressed, but no new compressed folders could be created.

Seem like minor annoyances in return for the extra I/O speed of 64k.

--ghg

i know i posted the solution to this a while back... now i just wish i could remember how it can be done in XP... i forgot (their was a trick to it...) totally... /cry



anyway, a thought might be to check the block size for that specific raid controller? is it 128k like most? try 32k then instead of 64k...

or try exFAT (64MB sizes... LMFAO)... im joking on that one... well kinda... i want to try it bad but lack a system for testing... /cry