FAT oder NTSF?

Servus Leutz,

ich hab winXP auf meiner IBM IC35060, partitioniert in eine "schnelle" 20GB C-Partition mit FAT32 und eine langsame Partition auch FAT mit 40GB für meine Daten.

Jetzt stellt sich mir doch langsam mal die Frage bei einer Neuinstallation von XP (beim Boardwechsel) sollt ich da meine C-Partition in NTSF umformatieren?

Was ist schneller?
Was ist sicherer?

Und wie komm ich mit ner DOS Startdiskette bei nem Cräsh auf die NTSF Partition?

Mfg G.willi

auf jedem Fall NTFS!

Schneller ? FAT32 !
Sicherer ? NTFS !

Ich würde in jedem Fall NTFS wählen, weil Du den geringen Unterschied in der Geschwindigkeit eh kaum bemerken wirst.

Zum Zugriff:
NTFS Reader for DOS
Allerdings nur Lesezugriffe.

was heißt sicherer? was kann ich mir davon kaufen?
wieviel schneller ist FAT?

wieso ist FAT schneller? ich dachte immer NTFS wäre ein bisschen fixer. kann mir das mal jemand erklären?

NTFS ist sicherer in puncto Multi-User. Du kannst besser bzw. überhaupt Freigaben und Restriktionen mit NTFS machen als mit FAT. Außerdem heißt es, dass bei einem Crash man mit NTFS weniger Risiko hat.

alles in allem ist NTFS einfach moderner

Original geschrieben von musicfriend
wieso ist FAT schneller? ich dachte immer NTFS wäre ein bisschen fixer. kann mir das mal jemand erklären?

Zum Vergrößern anklicken....

NTFS ist komplexer, höhere Komplexität bedeutet mehr Verwaltungswand, höherer Verwaltungsaufwand bedeutet niederigere Geschwindigkeit.
Ob der Unterschied wirklich spürbar ist, das weiss ich nicht (theoretische Benchmarks zählen jetzt nicht, da es um die Praxis geht).

http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=40042&highlight=NTFS

http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=5903&highlight=NTFS

http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=55830&highlight=NTFS

cu Garfield"...moment,EINWorthätteichdanndoch-Suchfunktion"X

NTFS ist sicherer und schneller!!!! Nur auf SCSI Platten kann es zur Performace Einbußen kommen da Microsoft aufgrund eines immer noch unbehebten Bug (trotz SP1) es nicht auf die Reihe gekriegt hat, obwohl der Patch drin sein soll!!! Naja aber allgemein ist NTFS schneller und sicherer und vor allem Sparsamer mit dem Festplattenplatz muss wohl jetzt nicht die Cluster Sache erklären oder ?

ich frag mich auch WO dieser mythos 'FAT(32) sei schneller' herkommt

Original geschrieben von OmaKuschel
ich frag mich auch WO dieser mythos 'FAT(32) sei schneller' herkommt

Zum Vergrößern anklicken....

k.A... schau doch mal Das_Wishnu Begründung...

Also ich habe auch noch KEIN Geschwindigkeitsunterschied zwischen NTFS und DAT bemerkt!
Aber wie in einem anderen Thread schon geschrieben...
NTFS verliert nicht sofort Daten wenn Dein System mal einfriert oder abstürzt!
Bei FAT darfst Du danach sofort nen Scandisk machen und hast mehr als oft verlorene Clulsterketten...

Kleiner Auszug aus
Welches nehmen: Das richtige Dateisystem von nickles.de .

"Jeder Ordner und jede Datei verfügt über eine Zugriffskontrolliste (Access Control List, ACL), in der User- und Gruppen-Konten mit der Art des Zugriffs eingetragen sind. Erfolgt ein Zugriff auf die Ressource, prüft NTFS diese Liste und erteilt oder verweigert den Zugriff. Aus diesem Grunde ist NTFS auch ein wenig langsamer als FAT."
Reicht das jetzt als Begründung ?

BTW: Ich habe auch keinen Geschwindigkeits-Unterschied festgestellt.
Das nur am Rande.

Original geschrieben von Devastators


k.A... schau doch mal Das_Wishnu Begründung...

Zum Vergrößern anklicken....

Hey, ich habe nie behauptet, daß man da einen Unterschied merken würde...aber komplexer bedeutet nun einmal auch mehr Aufwand...kann natürlich sein, daß es das an anderer Stelle wieder reinholt (besser organisiert etc.) ...oder aber, daß der Unterschied einfach nicht ins Gweicht fällt...

Warum fragmentiert NTFS langsamer?
Der Unterschied ist doch nicht nur bei der Rechtevergabe... es müssen physische unterschiede bei der Datenstruktur sein...

Aber wie gesagt... Performance ist egal.. merkt man keinen Unterschied.

zu diesem thema gibt es einen äußerst interessanten artikel von dmitry mikhailov,
der bei digit-life.com veröffentlicht wurde.

ich poste hier nur mal das fazit des artikels

Auszug aus
"FAT and NTFS performance" by Dmitry Mikhailov

http://www.digit-life.com/articles/ntfs/index3.html

3. Conclusions

FAT highs:

• The effective work requires few of RAM.
• Fast work with small and average directories.
• The disc implements less movements of the heads (as compared with NTFS).
• The effective work on slow discs.

FAT lows:

• Quick performance decrease with the fragmentation going up (only for FAT32).
• Difficulty in access to big files (more than 10% of the disc space).
• Very slow work with directories containing huge amount of files.

NTFS highs:

• Fragmentation does not influence the system performance (the work might became worse as far as data access is concerned).
• Complicity of the structure of directories and the number of files do not affect the performance.
• Quick access to the required file fragment (i.e. editing of big .wav files).
• Very quick access to small files (several hundreds bytes) - the whole file is located in the same place as the system data (MFT recording).

NTFS lows:

• The memory size mustn't be less than 64 MBytes.
• Slow discs and controllers without Bus Mastering slows the system performance down tremendously.
• The work with average-size directories is quite difficult, since they are fragmented.
• The disc working for a long time with 80% - 90% of its space occupied shows low performance.

Zum Vergrößern anklicken....

Festplatten Tweaks
FAT32 oder NTFS5
Bei Windows 2000 kann man sich zwischen den beiden Dateisystemen FAT 32 und NTFS5 entscheiden. Beide haben vor- und nachteile. FAT 32 kann auch von anderen Betriebssystemen wie Windows 98 und Linux gelesen werden. Wenn man also darauf angewiesen ist sollte man bei FAT 32 bleiben.


NTFS ist dafür schneller und sicherer als FAT32. Außerdem lassen sich mit NTFS Festplatten, Verzeichnisse oder auch nur einzelne Dateien komprimieren. Man kann also noch mehr Plattenplatz freimachen in dem man selten gebrauchte Dateien komprimiert.

Quelle http://www.tweakcentral.de/tweakguides/win2k/drives/win2k-13.shtml

Also...
der eine findet eine Aussage von dieser HP, der andere eine Aussage einer anderen HP... und die unterscheiden sich auch noch wie Tag und Nacht.

Nur damit dieses Erbsengezähle hier endlich mal aufhört...
und um es für Gangowilli zum Abschluß zu bringen,
denn sonst kann er ja nie installieren .
Hau XP einfach in NTFS drauf,
erfreue Dich an einem nicht zu merkenden Performance-Unterschied,
aber an mehr Sicherheiten. PUNKT !

@ Devastators

naja, die drei sätze bei tweak central sind doch recht dürftig

da ist der artikel von dmitry mikhailov doch extrem umfangreicher und fundierter.


@ Superdad

hast natürlich recht

schließlich muß sich ja auch fragen, was für eine zukunft fat32 noch vor sich hat.
microsoft hat da doch offensichtlich einen weg eingeschlagen, der als zukünftiges
filesystem doch eher auf ntfs aufbaut.



mfg
cruger

dankschön mal,
werd mich jetzt doch für NTSF entscheiden da ich langsam die schnautze mit den Fragmenten vollhaben tu
mal ehrlich sobald die Diablo2 files fragmentiert sind läuft des ganze spiel nimmer flüssig. Und ich kann 100 mal defragmentieren lassen der macht des ned hab immer 2 oder 3 fragmente bei den dateien *kopfschüttel*

Ok, dann halt mal etwas tiefergehend:

Um die Performance von FAT & NTFS technisch-direkt zu vergleichen sind die verwendeten Ansätze zu Verschieden.

FAT (auch FAT32 - deshalb schreib ich mal immer nur FAT) legen die Daten der FileAllocationTable NICHT vorsortiert ab.
Bei Dateizugriffen wird also erstmal in der FAT nachgeschaut, WO den der Datensektor, auf den Zugegriffen werden soll überhaupt liegt - das dauert bei fragmentierten FAT-Einträgen (FAT-Verweise auf sequentielle Datensektoren liegen nicht sequentiell vor) schon recht lange, da jeweils die FAT komplett neu durchsucht werden muss.
Diese einfache Strukturierung macht bei der Verwaltung KLEINER Datenmengen in wenigen Datein sinn (FAT wurde primär zur Verwendung bei Disketten entwickelt) stößt bei großen Datein (2GB Grenze) und sehr vielen Dateien aber eben auch schnell an seine Grenzen.

NTFS verwendet zur Allocation die MasterFileTable - diese hat 2 wesentliche Merkmale:
1. Datein und komplette Ordner kleiner als 1.5KB werden DIREKT in der MFT abgelegt - dadurch entfällt ein weiterer Lesezugriff, da MFT-Eintrag=Dateneintrag.
2. Die MFT ist als B-Baum aufgebaut - dadurch werden auch komplexe (fragmentierte) Suchen noch schnell(er als bei FAT) durchgeführt - der Performanceverlust durch Fragmente macht sich also nicht so deutlich bemerkbar.

Da NTFS ein JournalingFileSystem ist sind Datenzugriffe prinzipiell LANGSAMER als FAT-Zugriffe auf Daten - schlieslich wird der gesamte Vorgang mitprotokoliert (benötige zusätzliche Schreib/Lesevorgänge, inklusive HD-Kopfbewegungen) - da aber die MFT-Strukturierung wesentlich effektiver ist gleicht sich das in der Regel aus.
Durch das Journal werden Datentransferfehler erkannt und (meistens) vom Dateisystem (bzw. dem NTFS-Systemtreiber) selbst behoben.
NTFS kennt keine Filegrößenbeschränkung, Dateien können als Maximum so Groß wie die Partition werden.
Dabei verwendet NTFS bis zu Part.Größen von 4TB noch 4K-Cluster.

Fat(32) ist IMHO heute nicht mehr UpToDate.

@The Real Azrael:
Was hat IDE<->SCSI mit FAT<->NTFS zu tun? - Oder, von welchem SCSI-NTFS-Bug sprichst du da?
Seit WinNT wird doch auf SCSI-Arrays mit NTFS gearbeitet, und die sind doch schnell - oder hab ich die letzten Jahre was verpasst?

cu Garfield"hoffeeswarnochverständlich&nichtzusehrvereinfacht"X

2. Die MFT ist als B-Baum aufgebaut - dadurch werden auch komplexe (fragmentierte) Suchen noch schnell(er als bei FAT) durchgeführt - der Performanceverlust durch Fragmente macht sich also nicht so deutlich bemerkbar

Zum Vergrößern anklicken....

ich wusste gar nicht dass ein MS OS B-Bäume benutzt
wenn dies so sein sollte hat NTFS einen imensen geschwindigkeitsvorteil beim Lesen der Informationen
beim schreiben ist ein normales ungeordneter BlockFS natürlich das schnellste
da der baum bei jedem schreibvorgang , im worst case komplett neu geordnet werden muss
bei FAT wird einfach nur das neue hinten rangeklemmt was dann ja auch die fragmentierung ausmacht...

NTFS kennt keine Filegrößenbeschränkung, Dateien können als Maximum so Groß wie die Partition werden.

Zum Vergrößern anklicken....

vollkomener Blödsinn, durch den mathematischen aufbau eines computers gibt es für ALLES grenzen, ich glaube die max dateigrösse liegt bei 4EB... da bin ich mir aber nicht sicher auf jeden um einiges grösser als die max. Partitionsgrösse...
das ist aber bei so ziemlich allen FS' der Fall

Da NTFS ein JournalingFileSystem ist sind Datenzugriffe prinzipiell LANGSAMER als FAT-Zugriffe auf Daten - schlieslich wird der gesamte Vorgang mitprotokoliert (benötige zusätzliche Schreib/Lesevorgänge, inklusive HD-Kopfbewegungen)

Zum Vergrößern anklicken....

nicht ganz richtig, der vorgang wir nicht mitprotokolliert sondern... alles was getan wird wird in ein Journal (das log file ) geschrieben und dann von dem Manager ausgeführt und ein commit flag gesetzt... irgentwann erfolgt dann ein sync point

langsamer als nicht direkt eher ein wenig delayed... weil der schreibvorgang ein paar momentchen später efolgt...
ich wusste gar nicht dass NT ein physisches Journal führt

Fat(32) ist IMHO heute nicht mehr UpToDate.

Zum Vergrößern anklicken....

ich bin mir noch nicht mal sicher ob Fat32 vor 10 Jahren aktuell wäre...
mal ehrlich als mehr als eine krücke würde ich fat nicht bezeichnen...
fat12 und 16 sehen so arm gegen das zu der zeit schon erschienene ext2 aus...

fat kanns höchstens noch mit dem ewig alten minix FS aufnehmen...

und NTFS ist meiner meinung nach auch schon ein wenig angestaubt...
wenn ich da JFS XFS oder Reiser angucke...

Ich benutze seit Ewigkeiten FAT32 auf meinen Platten.

Meint ihr ich kann das so lassen oder würde ne Konvertierung in NTFS was bringen?

Original geschrieben von Tom24
...
vollkomener Blödsinn, durch den mathematischen aufbau eines computers gibt es für ALLES grenzen, ich glaube die max dateigrösse liegt bei 4EB... da bin ich mir aber nicht sicher auf jeden um einiges grösser als die max. Partitionsgrösse...
das ist aber bei so ziemlich allen FS' der Fall

Zum Vergrößern anklicken....

ähm, das es für Partitionen limits gibt ist keine Frage (z.Z doch 4TB bei NTFS, oder?) - nur NTFS kann als Dateigröße eben so weit gehen, wie es die Partition zulässt.
praktisch also max. Partitionsgröße=max. Dateigröße.
Bei Fat(32) max. Dateigröße=2GB.
Wie es bei anderen Dateisystemen aussieht war hier nie wirklich die Frage...

...
nicht ganz richtig, der vorgang wir nicht mitprotokolliert sondern... alles was getan wird wird in ein Journal (das log file ) geschrieben und dann von dem Manager ausgeführt und ein commit flag gesetzt... irgentwann erfolgt dann ein sync point
...

Zum Vergrößern anklicken....

Wo bitte ist in deiner Beschriebung der Unterschied zu dem was ich schrieb?

Ob Reiser oder ext3 besser sind oder nicht ist hier nicht der Punkt, es geht um FAT(32)<->NTFS.

@028:
Ich sage dazu prinzipiel: umwandeln.

cu GarfieldX

Original geschrieben von 028
Meint ihr ich kann das so lassen oder würde ne Konvertierung in NTFS was bringen?

Zum Vergrößern anklicken....

Algemein kann ich das nicht sagen.
Aber bei Bridge Commander hat sich die Ladezeit halbiert.

ähm, das es für Partitionen limits gibt ist keine Frage (z.Z doch 4TB bei NTFS, oder?) - nur NTFS kann als Dateigröße eben so weit gehen, wie es die Partition zulässt.
praktisch also max. Partitionsgröße=max. Dateigröße.
Bei Fat(32) max. Dateigröße=2GB.
Wie es bei anderen Dateisystemen aussieht war hier nie wirklich die Frage...

Zum Vergrößern anklicken....

nein es gibt auch limits für dateigrössen , is doch vollkommen logisch aber die sind schon seit langer zeit um einiges höher gesetzt als die part. grössen , daher ist deine aussage dass die max. dateigrösse unendlich sei,schlichtweg falsch... und auch sehr unlogisch wie ich schon vorher sagte

Wo bitte ist in deiner Beschriebung der Unterschied zu dem was ich schrieb?

Zum Vergrößern anklicken....

aus deiner aussage kommt hervor, dass Jfs' grundlegend langsamer sind, ich sagte nur sie sind nicht langsamer sondern arbeiten minimal verzögert
das ist für mich ein unterschied. und die erklärung nur deshalb damit mans nachvollziehen kann, ich möchte ja keine behauptungen in den raum stellen

wir diskutieren doch hier schliesslich

Ob Reiser oder ext3 besser sind oder nicht ist hier nicht der Punkt, es geht um FAT(32)<->NTFS.

Zum Vergrößern anklicken....

siehs mir nach, ich stell MS produkte gern in den schatten von unix "produkten"
und ein kleiner vergleich belebt die konkurenz
und ich fände es gut zu wissen wo ich mit einem MS Dateisystem stehe... bzw was andere können

@Tom24:

Ich wollte nie behaupten, das die Dateigröße bei NTFS unendlich sei - schlieslich schrieb ich schon oben, das die Partitionsgröße die Dateigröße limitiert, welche wiederum selber Limitationen unterliegt.

Du sagst, ein JFS arbeitet "verzögert" - ?? - ich sage, ein JFS ist langsamer, weil es ein Journal führt - den genauen Unterschied musst du mir echt mal erklären...
Klar, der reine Datentransfer ist genauso schnell wie ohne Journal, nur der GESAMTE Vorgang eines Zugriffes dauert eben länger.

Welche Vorteile hat den z.B. Reiser FS gegenüber NTFS?
Würd mich wirklich interessieren. Ich verwende z.Z. ext3 - ist AFAIK ja auch ein JFS, kennst du das näher?

cu GarfieldX