On Monday, 1 February 1999 at 8:46:10 +0100, Gerd Bitzer wrote:
G'day.
> Moinmoin,
>
> Oliver Fromme wrote:
>
>> Moin,
>>
>> Wir werden hier demnächst einen Squid als Proxy/Cache aufsetzen
>> (Cache-Größe so ca. 10 bis 15 Gb). Als OS kommt FreeBSD zum
>> Einsatz. Der Cache wird voraussichtlich über drei Platten ver-
>> teilt (alle SCSI-U2W).
>>
>> Wenn man dem Squid drei Partitionen gibt, verteilt er seine Ob-
>> jekte automatisch gleichmäßig darüber. Die Squid-Leute behaup-
>> ten, daß dies bei aktuellen Squid 2.0 ziemlich effizient sei.
>> Mein Frage ist nun: Kann man sich darauf verlassen? Oder wäre
>> es besser, die drei Partitionen mit ccd zusammenzustripen und
>> dem Squid "am Stück" zu überlassen? Hat da jemand Erfahrungs-
>> werte?
>
> Hmm, Striping mit Parity (kann das ccd ?)
Nein, wenn Du damit RAID-5 meinst.
> hätte zumindest den Vorteil, daß eine Platte ausfallen könnte, ohne
> daß das Gesamtsystem stehen würde.
ccd läßt auch dann ausfallen, wo's nicht nötig ist.
> Aber Striping mit Parity gilt auf jeden Fall als langsamer als
> Striping ohne Parity, wie sich das dann noch mit Squids Methode
> verhält .. ?
Ich kenne mich (noch) nicht mit squid aus. Im Prinzip ist aber eine
gute Anwendung immer noch besser als eine für die Allgemeinheit
gedachte Zugriffsmethode. Andererseits habe ich gehört, daß squid
eigentlich Kernel Threads erwartet, und daß daher FreeBSD (momentan)
Grenzen gesetzt sind.
>> (Und wenn ccd: Welche Parameter wären für das Striping empfeh-
>> lenswert?)
Und wenn ccd, dann doch lieber Vinum!
(http://www.lemis.com/vinum.html), das übrigens auch RAID-5 kann,
allerdings nur gegen (Auf)preis. Für's Striping empfehle ich
prinzipiell Streifen von zwischen 256 kB und 512 kB. Die meisten
Leute empfehlen deutlich kleinere Streifen, die haben aber ihre
Hausaufgaben nicht gemacht.
Greg
-- See complete headers for address, home page and phone numbers finger grog(at)lemis.com for PGP public key To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Mon 01 Feb 1999 - 09:15:56 CET