Bestes Filesystem für eine SSD platte

Grumpy

Lt. Junior Grade
Dabei seit
Okt. 2007
Beiträge
281
Hallo :)

Ich hab da mal eine frage. Auf meinen Netbook habe ich eine 8GB SSD Platte, welche zwar klein ist aber mir vollkommen reicht.

Nun bin ich als am hin und her zwischen Linux und Windows.

Meine frage lautet nun:

Welches FS ist am besten für SSD Platten geeignet?
Dabei ist es egal ob es ein windows only oder Linux only FS ist.

Danke und liebe grüße

Grumpy
 

DogLife

Lieutenant
Dabei seit
Okt. 2006
Beiträge
720
ext3 oder ext4 ist ganz gut, das kann man Windows aber leider erst nach der Installation beibringen, ist also quasi Linux only.
 

Grumpy

Lt. Junior Grade
Ersteller dieses Themas
Dabei seit
Okt. 2007
Beiträge
281
Sicher? Ich hab gehört, das durch das journal ( schreibt man das so? ) ein fast ewiger schreibforgang erfolgt, welcher die SSD schneller abnutzt.

Liebe grüße

grumpy
 

bu1137

Captain
Dabei seit
Apr. 2010
Beiträge
3.249
noatime hat mit dem journal zwar nicht direkt etwas zu tun, aber ist generell eine gute idee (und bei neueren kernels default, bzw. norelatime).
 

Fruchtnektar

Lieutenant
Dabei seit
Okt. 2003
Beiträge
938
Jua, hast recht.... ich verwechsel den Mist in letzter Zeit ständig. Wie soll man auch denn noch bei den ganzen Reisers, Butterflies und Exten (und was es da noch gibt) noch durchblicken :rolleyes:
 

Grumpy

Lt. Junior Grade
Ersteller dieses Themas
Dabei seit
Okt. 2007
Beiträge
281
Und wie deaktiviert man das genau?

Weil dann mach ich mir heute Mandriva drauf mit ext4 und deaktiviertem journal.
Meine SSD soll noch etwas halten :)

Liebe grüße

Grumpy
 

Dese

Commodore
Dabei seit
Jan. 2007
Beiträge
4.429
Sicher? Ich hab gehört, das durch das journal ( schreibt man das so? ) ein fast ewiger schreibforgang erfolgt, welcher die SSD schneller abnutzt.
erstens ist ntfs in JEDER beziehung den unter linux etablierten filesystemen weit unterlegen und zweitens benutzt auch ntfs journaling (z.m. wenn es unter win vista und win 7 genutzt wird).

ausserdem ist die menge an schreiboperationen immer noch gering genug, dass du bis zum abnutzen der ssd vermutlich schon holocrystale nutzt.

wie oben erwähnt ist jedoch noatime ne gute möglichkeit das zu optimieren. man kann auch generell die schreibzugriffe, auch für's journaling weiter reduzieren, bei extX systemen und auch bei vielen der anderen.

ext4 wäre zu empfehlen solange brtfs noch nicht als stable deklariert wurde.

im allgemeinen: vermeide MS filesysteme soweit wie möglich.

p.s. wenn du mit windows auf ne ntfs partition zugreifst, auf der auch dei auslagerungsdatei ist, tia, windows schreibt darauf so viel unnötig rum, wie niemand sonst.
windows paging ist ne einzige katastrophe.

EDIT: hab grad den letzten post gesehen. ich würd dir nicht raten journaling zu deaktivieren. es bringt fast nichts an performance unter normalen umständen und deine ssd läuft immer noch nen jahrzehnt mit journaling.

ssds verschleißen langsamer als normale HDDs!

edit2: sehe grad, dass deine ssd nur 8GB ist. die hält somit zwar deutlich weniger, aber gewinnen tust du mit deaktivierten journaling dennoch nicht viel. aber macht jetzt schon mehr sinn.
 
Zuletzt bearbeitet:

enteon

Commander
Dabei seit
Apr. 2009
Beiträge
2.092
gib als mount-option noatime an. also in der fstab einfach reinschreiben wo sonst defaults und so steht und beim manuellen mounten ein "-o noatime" mit angeben.

zum FS:
ich würde einfach mal gewagt sagen, dass btrfs einen blick wert wäre. es hat eine SSD option die glaube ich nicht dafür da ist wear-leveling zu betreiben. die restlichen features sind auch sehr verlockend und für ein noch junges FS ist es überraschend stabil, wohl weil es viel aufmerksamkeit bekommt.

Reiser4 ist aber auch noch sehr schnell. siehe http://www.phoronix.com/scan.php?page=article&item=reiser4_benchmarks&num=1. nur ist es halt nicht im kernel und nicht unbedingt stabil. ob es überhaupt überlebt finde ich auch fraglich.

ansonsten ist Ext4 für SSDs am schnellsten: http://www.phoronix.com/scan.php?page=article&item=intel_x25e_filesystems&num=1

für SSDs ohne wear-leveling braucht man dann natürlich eines der 3(?) dafür gemachten (linux-) dateisysteme.
 

Sukrim

Lieutenant
Dabei seit
Apr. 2009
Beiträge
956
Ich würde dennoch am ehesten NTFS einsetzen - btrfs ist noch in Entwicklung, ZFS ist ein Exot und verwendet SSDs eher als Cache und ext4 hat bis auf TRIM-Unterstützung in aktuellen Kernels auch keine anderen SSD Optimierungen eingebaut als NTFS (das seit bald schon einem Jahr auch auf Win7 getrimmt werden kann).


Allerdings frage ich mich schon, wie man bei 8 GB mit Windows (falls TRIM möglich auch noch Win7) gemütlich auskommen kann, daher dürfte es dann wohl doch Linux werden.


@Dese: NTFS beherrscht Kompression - welches verbreitete Linux FS kann das?
 

Dese

Commodore
Dabei seit
Jan. 2007
Beiträge
4.429
@Dese: NTFS beherrscht Kompression - welches verbreitete Linux FS kann das?
welches nicht? oder anders: bei linux sind zugriffe auf platten etc modularer gestalltet. man kann ganz einfach alles zwischenschalten, was man will. ob kompression oder verschlueselung.

und alles dazu ist vorhanden. vorteil ist zduem, dass man kompressionsmethode, vershcluesselungsmethoden selber wählen kann, auhc das key-protokoll. wenn man kein plan hat gehts auch 0-8-15.

tut mir leid, aber du wirst bei windows kein technisches feature finden, was tatsähclich ein feature ist und nicht schon jahrelang in der unix/linux-welt gang und gäbe ist.

ach und noch was: ext 4 ist unabhängig von ssd features besser. also, wenn ext4 genausoviel ssd optimirungen hat wie ntfs dann immer noch eher ext4. im übrigen ist der aufbau von ext4 so, dass weniger auf die platte schreiben zu gegriffen werden muss.

NTFS ist unter den modernen filesystemen das mit abstand schlechteste, in jeder beziehung: sicherheit, performance, speichereffizienz...
 
Zuletzt bearbeitet:

Sukrim

Lieutenant
Dabei seit
Apr. 2009
Beiträge
956
NTFS ist unter den modernen filesystemen das mit abstand schlechteste, in jeder beziehung: sicherheit, performance, speichereffizienz...
Gibt's dazu auch Fakten? Ich hab leider kaum Vergleiche von sinnvollen Werten gefunden (die NTFS-3g Implementierung ist dann doch wohl nicht das Wahre), dürfte aber auch deswegen schwer sein, weil man dann gleich mal wieder einen Windows/Linux Vergleich anzettelt. Vielleicht noch http://en.wikipedia.org/wiki/Comparison_of_file_systems - und da schaut NTFS auch nicht sooo mies aus.
 

enteon

Commander
Dabei seit
Apr. 2009
Beiträge
2.092
http://www.phoronix.com/scan.php?page=news_item&px=ODIxNw

man beachte auch:
While EXT4 has regressed a fair amount (as we have talked about in countless articles) since it was deemed stable in the mainline Linux kernel, it's looking like it's still able to hold its ground against Windows 7 and NTFS at least with this synthetic disk benchmark.
 

Sukrim

Lieutenant
Dabei seit
Apr. 2009
Beiträge
956
Sicherheit + Speichereffizienz wurden da gar nicht angeschnitten, ebenfalls nicht die sonstigen Features... und "mit Abstand das Schlechteste" in einem Vergleich von genau 2(!) Dateisystemen ist jetzt nicht gerade aussagekräftig, oder?

Am Besten für SSDs geeignet dürfte aber sowieso ein LogBased Filesystem sein, von denen aber nur wenige ausgereift und verbreitet sind...
 

Dese

Commodore
Dabei seit
Jan. 2007
Beiträge
4.429
der grund für die derzeit wenigen tests mit ntfs und anderen filesystemen ist, dass das schon ein ausgelutschtes thema ist. vor 5-10 jahren wurde da viel rumgetestet und diskutiert.

du kannst ja mal nach reiserfs, xfs, jfs, ext4, ext3 und ntfs googeln (am besten paarweise mit ntfs). dann findest du evtl noch alte vergleiche.
allerdings sind dies fast ausschließlich performance vergleiche.

bezüglich der sicherheit: konzeptionell ist das ntfs-fs theoretisch so sicher wie jedes andere auch. das problem ist hier mehr windows selbst, wie es damit umgeht. die anderen "nachteile" von ntfs ergebin sich aus dem design. einen test bzw vergleich findest du dazu nicht (oder nicht das ich wüßte).

speichereffizienz ergibt sich ebenfalls aus dem design. der unterschied ist hier aber gering.

wegen den log-based fs: ich sehe nicht das ssds davon profitieren. die idee der log-struktur wurde zur verbesserung des thoughoutputs bei platten gemacht, indem weniger seeks benötigt werden. es gibt zwar auch verwendung bei flashbasierten speichern, aber da um writes auf blöcke zusammenzufassen, was bei ssds heute der controler + cache schon macht.

d.h. ich hab so gut wie keine vorteile, aber alle nachteile der log-based filesysteme.
 

MountWalker

Fleet Admiral
Dabei seit
Juni 2004
Beiträge
12.655
NTFS mit TxF (übrigens eine Neuerung mit Vista) ist datensicherer als die meisten aktuell stabilen Linux-FS und datensicherer als HFS+. NTFS ist deutlich besser, als sein Ruf - es fragmentiert schnell und die Master File Table unterscheidet es von den üblichen Unix- und Linux-Dateisystemen, aber von der Datensicherheit braucht es sich derzeit nur vor ZFS und vielleicht bald vor btrfs verstecken - vor denen müssen sich die Exts, Reisers, UFS, JFS, HFS+ und XFS aber auch verstecken.
 

Dese

Commodore
Dabei seit
Jan. 2007
Beiträge
4.429
txf ist eifnach ntfs version des journaling. und nein, es nicht sicherer als das journaling von ext3, ext4 oder reiser oder jfs oder xfs.

der grund warum ntfs unsicherer ist, ist unter anderem die möglichkeit mehrere datenkanäle unter dem selben filenamen zu haben. wobei eigentlich hier nicht das dateisystem unsicher ist, sondern windows selbst, da es damit nicht sauber umgeht. in seltenen fällen kann es zu kontinuierlichen datenschwund und korruption kommen (hab ich mit win7 serlbst einmal erlebt). sind allerdings sehr besondere umstände die da zusammen kommen müssen.

sicherer als die stabilen unix filesysteme ist es ganz und gar nicht. im übrigen ist das txf selbst auch alles andere als ein vorbild seiner klasse.

ntfs bleibt in jeder beziehung, performance, stabilität und sciherheit unterm durchschnitt.
 

Dese

Commodore
Dabei seit
Jan. 2007
Beiträge
4.429
also, zunächst ist das prinzip des journalings überall mehr oder weniger gleich und damit auch gleich gut. bei einigen der etablierten unix-filesystemen gibt es aber die möglichkeit verschiedene arten/stufen des journaling zu schalten.

z.b. transaktionen mit vollen daten oder nur mit meta-daten (bei letzteren werden die eigentlich daten nicht mit ins journal geschrieben sondern nur infos wie z.b. woher die daten stammen - also ort auf der platte - etc.).

varianten der letzten version sind eigentlich standard, sowohl bei den unix filesystemen als auch bei ntfs. man kann ganz einfach aber weitere sicherheitsfunktionen für die unix-systeme aktivieren, auch bei einigen der filesysteme das volle journaling, was aber offenscihtlich auf die performance drückt. überdies gibt es unterschiede wie redundant infos zu den dateien gespeichert werden. die mat von windows, die redundante kopien hat ist da z.b. unflexibler und weniger sciher bei der rekonstruktion von verlusten. das hat aber nichts mit dem journaling zu tun.

aber das hauptproblem bei ntfs bezüglich der sicherheit ist nicht das journaling. ich hab ja auch nicht behauptet, dass das journaling bei ntfs prinzipiel unsicherer ist. ich sagte schelchter, weil weniger flexibel, weniger features.

unsicher ist ntfs durch diverse zusatzfeatures und deren schlechte implemmentierung in den windows treibern für das ntfs filesystem. das filesystem ntfs ist vom design her nicht per se unsciherer. es sit vom design her weniger performant, aber nicht unsicherer. aber da ntfs im grunde nur mit windows existiert (unter linux ist das nicht mehr als optionales feature für windows user) bemesse ich es auch an den problemen, die es im zsuammenhang mit widnows selbst hat und dessen implementierung für den zugriff.

eine sache macht aber ntfs schon vom design her unsciherer als alle anderen fielsysteme, eben diese channels (muss mal nach der genauen bezeichung nacher googlen). man kann damit wunderbar fremden daten und programme vetrstekecken und ausser mit spezieller software sind diese nicht sichtbar (auch nciht für admins!).

der witz ist aber, dass dieses vor jahren so euphorisch angepriesene feature nie richtig verwendung gefunden hat und der windwos code dafür in einem unfertigen und total verbuggten zustand ist. das ergebnis ist, dass bei verwendung von z.b. älterer software es durchaus manchmal zu problemen kommen kann.

in meinem fall hat ein installationprogramm einen teil der dateien in einen subchannel geschrieben (das war nicht vom programm beabsichtigt, sondern auf grund eines windows bugs so umgeleitet worden). danach konnt cih einen teil der dateien nur sehen, wenn ich im fileopen menu der isntallierten software schaute. im explorer oder sonst wo waren sie nicht zu fidnen.

überdies leif die sopftware nicht richtig, weil sie deswegen teile der daten nicht fidnen konnte.

und noch besser. das zog ne ganze kette von problemen mitsich, da ab dem tag cih datenverlust bekam, solange bis ich gezwungen war windows 7 zu löschen und neuzuinstallieren. immer mehr dateien wurde in die subchannels verschoben.

nach verdammt langer recherche hatte ich infos darüber gefunden, dass es ganz selten zu sowas kommen kann (vista) und ich wohl einer der ersten und bisher wenigen war, die das vergnügen nun auch unter win 7 hatten.
Ergänzung ()

ach ja, diese subchannel geschichte nennt sich "Alternate data streams". gibts auch bei anderen filesystemen, ist also nichts ntfs eigenes. aber unter windows gibt es keine buildin möglcihkeiten diese einzusehen. man muss ein extra tool dafür runterladen und isntallieren.

es sind auch immer wieder datenkorrumptionsprobleme auf der offiziellen ms seite dazu bekannt gegeben. z.b. gabs mal (oder gibt es immer noch) probleme in diesem zusammenhang mit dem ms home server.
Ergänzung ()

hier noch mal auf die schnelle ein paar interessante infos und tests zu den alternate datastreams und ntfs:
http://www.symantec.com/connect/articles/windows-ntfs-alternate-data-streams

edit: ja ich weiß, der artikel ist schon älter und der dort beschriebene exploit funktioniert genau so nicht mehr. aber es gibt genügend anderen probleme weiterhin damit. undfertigen code in windows und ms software gibts tonnenweise.
 
Zuletzt bearbeitet:
Top