🚀 go-pugleaf

Th.Huber (judas@tomtec.abg.sub.org) wrote:
>Tja, dann frage Ich mich, warum BFS fuer envoy das gleiche Problem nicht hat,
>setzt es doch ebenfalls auf dem darunterliegenden filesystem auf.
>
>Ein Bild mittels Retinadisplay angezeigt, dauert bei EFS ca. 2min (!), waehrend
>BFS schlappe 20sec benoetigt.

Tja, schick mir doch mal packet snoopdos logs (bitte mit %t im
Buffer format!) des clients und und des servers für genau diese
Aktion mit aktuellen Rechnerkonfigurationsdaten und
lib/device-Versionen. Einmal mit EFS, dann mit BFS. Dann kann ich
Dir wohl dazu mehr sagen.

Mangels Bild und Retina[display] kann ich das nicht selbst
nachvollziehen.

Für Envoy 2.0 gibt es immer noch envoy-help@iam.com und
envoy-bugs@iam.com.

Wie immer gilt:

    Man kann nur das sinnvoll ändern oder verbessern, was
    reproduzierbar ist und von dem man weiß.

>Ein simples file kopieren koennen beide systeme, nur wenn ein file stueckweise
>gelesen wird, ist BFS eindeutig besser.

EFS in Envoy 2.0 optimiert keine Seek(fh, 0, OFFSET_CURRENT)
Zugriffe. Sie werden in 2.0 auch zum Server durchgereicht, damit
man auf jeden Fall die tatsächliche Serverposition bekommt. Wenn
eine SW also z.B. ftell() kontinuierlich einsetzt weil sie zu doof
ist sich die aktuelle Position zu merken, dann wird EFS aus Envoy
2.0 "langsam". Die nächste Envoy Version wird da optimieren.

Das kann hier aber nicht das Problem sein, denn BFS optimiert
überhaupt nichts. Alles wird synchron per DoTransaction()
durchgeführt, selbst R/W-Zeug. Ohne Rücksicht auf Verluste. Noch
dazu ist BFS IMHO eine Fragmentierungsbombe. Wer das mag ...

Ich bin gespannt auf die snoopdos logs.

-- 
Heinz Wrobel        Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email