> - Tagged Command Queuing TQC (bzw. das sog. Native Command
> Queuing NQC)
> bringt nur in multi-user-Umgebungen einen Vorteil, bei
> single-user-Nutzung bremst der entstehende Overhead sogar -
> und das spürbar
Zumindest hierüber habe ich aber bereits andere Resultate gesehen. In
einem Dateisystembenchmark der iX (einfaches rekursives Kopieren und
Löschen, also nichts Multi-User-ähnliches) brachte Command Queueing
(allerdings die Original-Variante nicht die billigen IDE-Kopien TCQ oder
NCQ) auf einem FreeBSD-System mit FFS und Softupdates eine signifikante
Geschwindigkeitssteigerung, die in etwa gleich groß war wie die
Geschwindigkeitssteigerung durch Einschalten des Schreibcache.
Interessanterweise brachte das Einschalten *beider* Features keinen
nennenswerten zusätzlichen Geschwindigkeitsvorteil gegenüber dem
Einschalten nur eines der beiden Features. Anders ausgedrückt kann man
also auch sagen, dass -- zumindest in diesem Benchmark -- Command
Queueing performancemäßig den Schreibcache ersetzen kann, ohne jedoch
dessen Nachteile bezüglich Datensicherheit zu besitzen. FFS Softupdates
sind allerdings als Weiterentwicklung von Journalling Filesystems schon
ein ziemlicher Spezialfall, ich weiß daher nicht, wie sich diese
Beobachtung etwa auf Journalling Filesystems wie ext3, JFS, XFS oder
Reiserfs übertragen lässt oder wie sich das auf die Wandering Logs von
Reiser4 auswirkt.
jwm
Received on Fri Jan 14 16:58:09 2005