Ich habe als Datenfestplatte (wird also nicht begootet von) eine 40GB Platte (die eventuell später durch eine größere ersetzt wird) und möchte da maximalgroße und möglichst sichere Partitionen haben. Diese sitzt auf einen 4fach Adapter (VOB) und es ist Idefix97 installiert um darauf zuzugreifen. Das ganze läuft unter OS3.9+BB2+ROMUPDATE.

Ich konnte mich aber zwischen den beiden Filesystemen noch nicht entscheiden. Desewgen führe ich hier die mir bekannten Punkte ein und hoffe das ihr diese ergänzen bzw. berichtigen könnt


FFS
-----
max. Partitionsgröße 108GB
max. Filezeichenlänge 31
Geschwindigkeit: Schlechter als SFS
Filesicherheit: Niedrig


SFS
-----
max. Partitionsgröße 137GB
max. Filezeichenlänge ?
Geschwindigkeit: Besser als FFS
Filesicherheit: Hoch

CU TerA
--
TerAtoM
(A4K 604e/233MHz 060/50MHz 146MB CV64_3D+SD)
Band: http://www.TERATOM.de
Privat: http://www.TerAmigA.de.vu
Profession: http://www.Xavo.de
ICQ: 18056588

[ - Antworten - Zitieren - Direktlink - ]

@TerAtoM:

Filezeichenlänge ist bei SFS glaub 256. Wichtig wenn du
MP3 Files vom PC rüberkopierst. Also ich würde auf
keinen Fall FFS verwenden... es gibt aber auch einige
die nie SFS verwenden würden...



--
cu, aPEX

Bild: http://www.a1k.org/bilderlink/a1000_lorbeer.gif A1000 Phoenix Revival Project http://www.a1k.org

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

FFS
-----
Filesicherheit: Niedrig


SFS
-----
Filesicherheit: Hoch

---

[ - Antworten - Zitieren - Direktlink - ]

Ein paar Bemerkungen zu SFS:

max. Partitiongröße: 2 TB (bis 128 TB je nach Blocksize)
max. Filezeichenlänge: 107 (Dateien, Ordner), 255 (Verzeichnisse [Pathes])



--
PegasosForum - Deutsche Pegasos Community
AmigaWorld - Amiga Support Network

[ - Antworten - Zitieren - Direktlink - ]

Ich würde dir FFS empfehlen und nich son 3rd party zeug.

Ich hab mit SFS und PFS nur schlechte erfahrung gemacht. Vielleicht liegts auch daran das ich nen Fastata hab und dort ganz bestimmte mask und maxtransfer werte eingegeben werden müssen damits richtig läuft

mfg cego
--
Yo let me talk to you,
let me have a word with you
If you're doing something else i hope i'm not disturbing you...
But if I am, so what!?
Stop IT!!!

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Zitat:

---

FFS
-----
Filesicherheit: Niedrig


SFS
-----
Filesicherheit: Hoch

---

Falsch. Es ist genau umgekehrt. Bei SFS wird eine Datei, die nicht vollständig gespeichert wurde, komplett gelöscht. Bei FFS wird die angefangene Datei in das Verzeichnis eingebunden und die Partition als Invalide eingestuft. Durch das anschließende Validieren kann die Datei in den meisten Fällen gerettet werden.

Gruß Thomas
--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
Bei SFS wird eine Datei, die nicht vollständig gespeichert wurde, komplett gelöscht. Bei FFS wird die angefangene Datei in das Verzeichnis eingebunden und die Partition als Invalide eingestuft. Durch das anschließende Validieren kann die Datei in den meisten Fällen gerettet werden.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von DJBase:
Ein paar Bemerkungen zu SFS:

max. Partitiongröße: 2 TB (bis 128 TB je nach Blocksize)
max. Filezeichenlänge: 107 (Dateien, Ordner), 255 (Verzeichnisse [Pathes])

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Bei mir sinds bei FFS wie bei SFS fast 10MB/s.

---

Hm, ich denke, beide haben ihre Schwächen und Stärken... SFS ist vom Design her vor allem bei Aufgaben sehr schnell, die nicht multithreaded sind. FFS dagegen flotter uns sehr sicher, wenn sehr viele Prozesse gleichzeitig aufs selbe Filesystem (gemeint ist die Partition, Diskette oder was auch immer) zugreifen.

Sehen kann man das sehr schön beim Booten eines OS3.9-Systems. Da ist SFS (handgestoppt) bei mir etwa 4 Sekunden langsamer als FFS (beides Mal auf ner IDE-Platte) bei eine Blockgröße von 2KB für FFS.

FFS ist in Sachen Datensicherheit ein zweischneidiges Schwert, einerseits läßt sich ein korruptes Filesystem nahezu immer wieder herstellen (ganz ausschließen kann man einen Totalverlust aber nie), dafür sind auch fast immer die zuletzt geschriebenen Daten futsch (wie Holger schon sagte, entsteht beim Validieren häufig eine "Mischdatei". Wenn das z.B. eine .drds (DrawStudio) ist, deren "vorderer" Teil nicht mit dem "hinteren" übereinstimmt, ist Sense. Datei unbrauchbar...). Bei SFS hat man wenigstens noch die alte Version der entsprechenden Datei.

Dafür ist bei SFS fast gar nichts mehr zu retten, wenn (was durchaus vorkommt) die Struktur des Filesystems so "zerstört" wurde, daß SFS selbst nichts mehr beheben kann (hab diesen Fall bei SFS schon einmal gehabt, bei PFS3 öfter). Bei den FFS-Partitionen gabs in 10 Jahren nicht einen Totalverlust bei den Partitionen auf meinem 4000er.

Großer "Nachteil" bei FFS sind die kurzen Dateinamen, aber das kann man mittels einer gewissen Ordnung in Bezug auf Verzeichnisse recht einfach umgehen. Bei SFS kann man dafür einfach alles auf die Platte werfen, wie es ankommt.

Nachdem ich entdeckt habe, daß viele Probleme der asyncio.library vor allem von den Designschwächen der "Atomic access"-Filesysteme (und deren Single Thread Design) herrühren, stelle ich gerade alles wieder auf FFS um, was bis jetzt SFS war.

So ne "richtige" Empfehlung wage ich aber trotzdem nciht auszusprechen, da eben beide Filesysteme Schwächen und Stärken haben. Wenn einen die kurzen Dateinamen und das Validate-Theater bei FFS nicht stören (man sollte übrigens die Partitionen trotz allem nicht größer als 2GB machen, weils sonst bei Validate zu Speichermangel kommen kann. Tödlich!), sollte man vielleicht eher FFS verwenden. In allen anderen Fällen SFS oder, wenns denn sein soll, PFS3.

Grüße



--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Nur zwei dieser Tests liefern überhaupt eine MB/s Angabe. Und auch diese müssen mit Dateien unterschiedlicher Größe durchgeführt werden.
Scanne mal die ID3-Tags (v1) eines Verzeichnis mit 100 mp3-Dateien mit mind. 3MB pro Datei. Einmal mit SFS und dann mit FFS, dann weißt Du, wie man Geschwindigkeit von Dateisystemen vergleicht.

---

Danach führst Du diese Tests zwei- oder mehrmals _gleichzeitig_ auf das selbe Filesystem aus, und schon sehen die Ergebnisse wieder ganz anders aus

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

hmm also ich nutz auch beides , eigentlich SFS nur wegen amigift grosse unterschiede konnte ich jetzt auch nicht ausmachen wer die 107 zeichen wirklich braucht (ich ja nicht:) ) wird aber um SFS nicht drum rum kommen ... .
aber das FFS irgendiwe unsicherer sein soll kann ich jetzt nicht nachvollziehen also mir hat das FFS nie sorgen gemacht (besonders seit dem os3,9 FFS!) . gerade das neue FFS vom 3.9 issja schon verdammt gut selbst wenn mal meine 5 gb platte nen validating machen muss dauert das bei weitem nicht mehr so lang gut 5 min vielleicht also solte man das selbst bei 40 gb noch verschmerzen koennen denn wie oft kommt sowas vor alle 2 schaltjahre ? . auch das thema defragmentation ist seit 3.9 extrem besser geworden undter 3.1 konnte ich das noch richtig mercken wenn laut reorg die fragmentation auf ueber 20% kam ,aber beim neuen FFS merckt man es oft nicht wirklich bei fast 40% .
mfg Bluebird

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Sehen kann man das sehr schön beim Booten eines OS3.9-Systems. Da ist SFS (handgestoppt) bei mir etwa 4 Sekunden langsamer als FFS (beides Mal auf ner IDE-Platte) bei eine Blockgröße von 2KB für FFS.

---

Du hast aber SFS nicht auch mit 2KB-Blockgrößen gequält, oder? Ich gebe zu, ich bin nicht mehr ganz auf dem Laufenden, was aktuelle Versionen angeht, aber bei mir war SFS immer _wesentlich_ schneller als FFS (unabhängig von der Blockgröße bei FFS - außer vielleicht 8 oder 16KB - aber so viel Plattenplatz hatte ich seinerzeit nicht zum Verschwenden

Und ich meine mich erinnern zu können, daß grundsätzlich Blockgrößen von 512 oder max. 1024 für SFS empfohlen wurden...

Gruß
Neodym

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Neodym:

Zitat:

---

Original von whose:
Sehen kann man das sehr schön beim Booten eines OS3.9-Systems. Da ist SFS (handgestoppt) bei mir etwa 4 Sekunden langsamer als FFS (beides Mal auf ner IDE-Platte) bei eine Blockgröße von 2KB für FFS.

---

Du hast aber SFS nicht auch mit 2KB-Blockgrößen gequält, oder? Ich gebe zu, ich bin nicht mehr ganz auf dem Laufenden, was aktuelle Versionen angeht, aber bei mir war SFS immer _wesentlich_ schneller als FFS (unabhängig von der Blockgröße bei FFS - außer vielleicht 8 oder 16KB - aber so viel Plattenplatz hatte ich seinerzeit nicht zum Verschwenden

Und ich meine mich erinnern zu können, daß grundsätzlich Blockgrößen von 512 oder max. 1024 für SFS empfohlen wurden...

---

Neee, SFS hat bei mir immer nur 512er Blöcke gehabt, eben wegen der ausdrücklichen Warnung vor größeren Blöcken in der Doku

Die 2048er Blöcke des FFS machen sich bei mir schon enorm bemerkbar, vor allem, wenn neben zahlreichen Lesevorgängen noch der eine oder andere Schreibvorgang stattfindet. Dann bricht SFS gnadenlos ein (zumindest bei mir auf dem 4000er, aber auch auf dem A1) und FFS macht fast genauso schnell weiter, als wäre das nichts besonderes. Größter Minuspunkt für mich selbst ist mehr, daß FFS anfängt zu schleichen, sobald _sehr viele_ Dateien neu geschrieben werden (also nicht überschrieben sondern neu angelegt werden). Das kommt aber in der Praxis eher selten vor.

Wie gesagt, muß jeder für sich selbst entscheiden, was er nimmt. Wenn AmigaAMP mich nicht drauf gebracht hätte, daß SFS Probleme bei sehr vielen Zugriffen gleichzeitig mit sich bringt, würde ich es auch weiterhin einsetzen, wie ich es halt die drei Jahre zuvor schon tat. Bis auf den einen Totalverlust einer Partition (keine Ahnung, was da schiefging) gabs nie Probleme und die gelegentlichen AWeb-Abstürze hatten dank SFS keine Validierungs-Zwangspause zur Folge.

Für den jetzigen FFS-Einsatz habe ich aber eine recht kleine Partition als Cacheverzeichnis vorgesehen (50 MB, die als "schäbiger Rest" übrigbleiben würdenI-) ), da dauert ein Validate auch nur ein paar Sekunden und wird schon während des Bootens fertig

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
Bei SFS wird eine Datei, die nicht vollständig gespeichert wurde, komplett gelöscht. Bei FFS wird die angefangene Datei in das Verzeichnis eingebunden und die Partition als Invalide eingestuft. Durch das anschließende Validieren kann die Datei in den meisten Fällen gerettet werden.

---

Zitat:

---

Original von DJBase:
Ein paar Bemerkungen zu SFS:
max. Partitiongröße: 2 TB (bis 128 TB je nach Blocksize)
max. Filezeichenlänge: 107 (Dateien, Ordner), 255 (Verzeichnisse [Pathes])

---

Die Festplatte hängt am internen IDE Port (scsi.device und IDEFix) und der unterstüzt nur LBA28, womit sich "nur" 128GB (2^28*512) ansprechen lassen. Macht man die Partition grösser ÜBERSCHREIBT das System einfach alle vorderen Daten... (Quelle: http://www.amiga-news.de/forum/thread.php3?id=17328&BoardID=1 ) Müsste mal sehen ob Buddha oder ähnliche LBA48 können.

CU TerA
--
TerAtoM
(A4K 604e/233MHz 060/50MHz 146MB CV64_3D+SD)
Band: http://www.TERATOM.de
Privat: http://www.TerAmigA.de.vu
Profession: http://www.Xavo.de
ICQ: 18056588


[ Dieser Beitrag wurde von TerAtoM am 17.06.2005 um 00:13 Uhr editiert. ]

[ Dieser Beitrag wurde von TerAtoM am 17.06.2005 um 00:46 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von TerAtoM:
Die Festplatte hängt am internen IDE Port (scsi.device und IDEFix) und der unterstüzt nur LBA28, womit sich "nur" 137GB (2^28*512) ansprechen lassen.

---

Falsch. Es lassen sich "nur" 128 GB ansprechen.

Hier die Rechnung zum nachrechnen:

2^28*512 bytes (!) = 137.438.953.472 Bytes (!)
geteilt durch 1024 = 134.217.728 KILObytes (KB)
geteilt durch 1024 = 131.072 MEGAbytes (MB)
geteilt durch 1024 = 128 GIGAbytes (GB)

So und nicht anders.

[ - Antworten - Zitieren - Direktlink - ]

@Crystal:

Hehe... habe ich korrigiert... irgendwie hatte ich auch noch 128GB im Kopf... aber in dem Thread stand ja 137... also habe ich einfach abgeschrieben

CU TerA
--
TerAtoM
(A4K 604e/233MHz 060/50MHz 146MB CV64_3D+SD)
Band: http://www.TERATOM.de
Privat: http://www.TerAmigA.de.vu
Profession: http://www.Xavo.de
ICQ: 18056588

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@ TerAtoM

quote:

Hehe... habe ich korrigiert... irgendwie hatte ich auch noch 128GB im Kopf... aber in dem Thread stand ja 137... also habe ich einfach abgeschrieben

Habe eben mal eine berühmte Suchmaschine angeworfen.

Suchbegriffe  Treffer

LBA28  128GB |  13
LBA28 137GB | 152

LBA48  128PB |   2
LBA48  144PB |  19

Du siehst, Du hast Dich wieder einer Minderheit angeschlossen

mfg Palgucker

[ - Antworten - Zitieren - Direktlink - ]

@Palgucker:

Sind wir mit unserem Amiga-Hobby nicht auch in einer Minderheit?

Irgendjemand aus diesem Forum hat (oder hatte) in seiner Sig stehen: Nur weil viele Leute das gleiche behaupten, heißt das nicht zwangsläufig, daß sie damit recht haben. (oder so ähnlich)

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Nachdem ich entdeckt habe, daß viele Probleme der asyncio.library vor allem von den Designschwächen der "Atomic access"-Filesysteme (und deren Single Thread Design) herrühren, stelle ich gerade alles wieder auf FFS um, was bis jetzt SFS war.

---

[ - Antworten - Zitieren - Direktlink - ]

@Holger:

Lies dazu einmal die Ausführungen von Olaf Barthel, die er in Bezug auf FFS2 geschrieben hat. Da findest Du sehr interessante Informationen u.A. über die Parallelisierung, die bereits das alte FFS zur Verfügung stellte. Das hat übrigens mit der Reihenfolge des Eintreffens der Packet-Messages an einem Handler-Port weniger zu tun als mit der Bearbeitung derselben und der Bereitstellung der Daten für die "Antwort". Da wird ziemlich massiv parallelisiert, oder was meinst Du, wie es sonst möglich ist, daß mehrere Prozesse/Tasks _ein_ Filesystem scheinbar _gleichzeitig_ ansprechen können?

Im Übrigen: Was hat Multithreading mit mehreren Instanzen zu tun?

Zusätzlich zu den Informationen von Olaf solltest Du Dir mal das Verhalten von z.B. YAM2.x betrachten, wenn ein sehr gut gefüllter Eingangsordner vor dem Öffnen des Listview gelesen wird. Und wenn die ganze Geschichte wieder geschlossen wird.

Rate mal, welches FS YAM diese Aufgaben _deutlich_ schneller abarbeiten läßt...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Das hat übrigens mit der Reihenfolge des Eintreffens der Packet-Messages an einem Handler-Port weniger zu tun als mit der Bearbeitung derselben und der Bereitstellung der Daten für die "Antwort". Da wird ziemlich massiv parallelisiert, oder was meinst Du, wie es sonst möglich ist, daß mehrere Prozesse/Tasks _ein_ Filesystem scheinbar _gleichzeitig_ ansprechen können?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Crystal:
Falsch. Es lassen sich "nur" 128 GB ansprechen.

Hier die Rechnung zum nachrechnen:

2^28*512 bytes (!) = 137.438.953.472 Bytes (!)
geteilt durch 1024 = 134.217.728 KILObytes (KB)
geteilt durch 1024 = 131.072 MEGAbytes (MB)
geteilt durch 1024 = 128 GIGAbytes (GB)

So und nicht anders.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Dreimal darfst Du raten warum.

---

Klär mich auf.

[ - Antworten - Zitieren - Direktlink - ]