What file system is your HD running @

[`schr0et]

Ok I want to know what file system your using to run your HD on.

FAT32 or NFTS, if NFTS/NTFS are you using:

512byte
1kb
2kb
3kb
4kb?

Thx windows is pissing me off, accidently set one of my ram values wrong got 3 BSOD's and HD got corrupted :lol:

M$ is turning me into a retard, need to get back on my linux rig :wierd:

[PTK]

NTFS and 4kb [ not sure, but i would assume its 4kb ... @ work so cant check ;) ].

Pe-Te

[st0nedpenguin]

NTFS all the way baby, I wouldn't touch FAT32 again if my life depended on it. :D

I'm still running whatever cluster size is default for XP Pro, saw no reason to change it.

[nailbomb]

NTFS, 4k clusters.

[dim3z]

ive always been told that NTFS is the fastest so i use that. seems like a pretty simple choice to me.

[`schr0et]

Rgr that I'm currently on my A64 rig, dling SP1a finally after so many formats, pos M$!

After I install SP1a I'll get the rest of the stuff installed.

[Spec3]

NTFS for me too.

[STEvil]

NTFS, default cluster alloc.

[Szymek]

FAT32 :toast:

It is way faster than NTFS but partition size is mimited to ~190GB AFAIR

[Peckers]

Originally posted by Szymek
FAT32 :toast:

It is way faster than NTFS but partition size is mimited to ~190GB AFAIR

don't think so. Filesize is limited to 4GB though.
I wouldn't recomend anyone using FAT32 on a modern computer, NTFS will be just as fast even on smaller discs. I don't know how the performance is on _really_ small discs though. XP won't even let you format to FAT32 on discs larger than 32GB, guess why ;)
I _belive_ that clustersize automatically increase with the disc size in FAT32, and can not be manually set..which sucks..

for a windows disc NTFS with 4kb is the only way to go since you have so many small files there, cookies etc..
lets say you got a disc with mostly large movie files, then you could increase the clustersize to avoid some of the fragmenting.

[sjohnson]

Still running FAT32/Win2k here, at home. 32gig/partition is a FAT32 limit.

No need for ACL's, the speeds are nearly identical, no MFT wastage and I have had zero problems with FAT corruption that couldn't be repaired.

No "NTLDR" not found messages, I have access to the HD from a DOS-boot floppy (flashing from my HD, no worries about making floppy or CD flash disks).

Data recovery on a scrambled NFTS partition is a miserable task. Done it many times in the datacenters where I've worked.

At work, and whenever I need either >32 gig partitions or ACL's I use NTFS. Else, FAT32 all the way. Encryption? PGP works on either FAT32 or NTFS and is worlds better than NTFS encryption IMO.

For a real filesystem, throw away your Win2k/XP and run Linux or Solaris. Realtime, *REAL* auto-defragmentation, REAL filesystem hardening. MicroSoft needs to drop the 20 year-old VAX/VMS filesystem they call NTFS and move into the 21st century.

[Peckers]

Actually the 32gb limit is a restriction in newer windows versions, in the way that you cannot format larger partitions than 32gb. FAT32 itself supports up to 128GB partitions and Win XP(2k to I guess) can use these partitions aswell.

Another good thing with NTFS is that it log all changes being made so that if you have an unexpected stutdown windows can easily check and correct any errors while with FAT you have to check the whole filetable(scandisk..).
I have no experience with data recovery so I assume You're right about that. I agree that a new filesystem for windows platforms would be very nice but as it stands now I still consider NTFS being the best choise for the wast majority of users.

[sjohnson]

chkdsk is used on FAT under win2k. I really don't see any speed advantages in chkdsk, FAT32 vs NTFS. Either filesystem can have a quick or a long chkdsk session.

It would be great if some guru could force similar disk problems, then time chkdsk on FAT and NTFS to get a bench comparison.

I've seen a 300 gigabyte NTFS filesystem (SCSI, in an EMC RAID 5 config) on a Win2k server take in excess of 18 hours to complete a chkdsk. File-handle scrambling induced by extremely heavy NFS (Network File System) access from a UNIX system caused the need for that chkdsk. Stupidly, the 300 gigs were used as a spool to feed an Oracle database on the UNIX box. And stupidly, the developers wouldn't use SMB because - at the time - "SMB is freeware from those Linux wackos, and it has no support" Yah, right :rolleyes: