... 100MB¹

Potwierdzają to moje obserwacje przytoczone w rozdziale 4. System XWindows korzysta z ok. 50MB plików.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... klientów²

W rozdziałach 3.2 i 3.3 klient oznacza komputer, a nie użytkownika.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... pakietu³

Przy nierealistycznym załóżeniu, że dane są przesyłane z prędkością 10Mb/s i 155Mb/s dla sieci Ethernet i ATM, odpowiednio. Zakłada się jednak, że dla ATM rozwój technologii umożliwi taki transfer w rzeczywistości.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... bloku⁴

Przez czas życia bloku rozumie się czas pomiędzy pierwszym odwołaniem się do niego, a usunięciem go z rozproszonego schowka, lub usunięciem jego singletonu, lub zamianą singletonu na 'normalny' blok.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... V⁵

Założenie sprzeczne ze spostrzeżeniami o lokalności odwołań do plików.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... schowka⁶

Jest to zgodne z zachowaniem się procesu gromadzącego dane (ang. hoard walking), który cyklicznie waliduje wszystkie dane schowka.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... klienta.⁷

Nawet wtedy, gdy w schowku nie ma zmodyfikowanego pliku . To rozwiązanie jest bardzo nieefektywe, a sposób poprawy bardzo prosty. Jest on opisany dalej w tekście.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... schowka⁸

W systemie Coda zawartość wolumenu u kienta jest zdeaktualizowana nawet w przypadku, gdy zmieniony jest plik nie znajdujący sie schowku klienta.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... serwera⁹

Zakładam, że klient chce mieć dokładnie ten sam zbiór plików w wolumenie jaki miał przed modyfikacją. Jednak ze względu na fakt, że prawdopodobieństwo, że plik będzie powtórnie modyfikowany w niedalekiej przyszłości jest duże, klient powinien żądać nowej kopii pliku tylko w momencie gdy występuje do niego odwołanie.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... psedourządzenie¹⁰

Wirtualne urządzenie systemu Linux.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... moduł¹¹

Mam tu na myśli wydzielony fragment kody, a nie moduł jako część systemu operacyjnego Linux.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... żądania¹²

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... znacznego¹³

Jak pokazują testy przedstawione w p. 4.7 przy dobrze skonstruowanym procesie cacheCleaner nie jest to więcej niż 10%. Dobrze skonstruowany proces cacheCleaner utrzymuje na stałym poziomie ilość wolnego miejsca w schowku. Można to osiągnąć poprzez budzenie procesu w momentach małej aktywności systemu, po to, aby usunął ze schowka część starych danych.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... RPC¹⁴

Greg Badros nie modyfikował warstyw RPC, więc tak mniejsza ilość komunikatów nie wynika z efektywniejszego działania RPC.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... sam¹⁵

Greb Badros nie podaje jaki rozmiar miał schowek. Generalnie jednak jego założenie było takie, że do schowka się przeważnie pisze a usuwanie danych występuje rzadko. Stąd zakładam, że schowek nie był czyszczony w trakcie wykonywania testów.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.