[FreeBSD] Which OS is fastest for High Performance Network Applications?

[Miklos Niedermayer]

Hello,

On Fri, Jun 08, 2001 at 10:18:42PM +0200, Gabor Dolla wrote:

> en nagyon nem kovetek mar regota semmilyen listat :) igy nem vagyok kepben
> (ok, a cache kikapcsrol mar hallottam, lehet, hogy ezen a listan volt :)
> szoval, ha en tudom, hogy az en ide-s vinyom tuti jo cache-u, akkor
> kezzel visszakapcsolhatom ?

Persze, van rá egy sysctl.  (hw.ata.wc ha minden igaz)  Annyi, hogy ezt
csak loader.conf-ból tudod megtenni ugyanis ha már fel van élasztve az ATA
eszköz, akkor már nem.


> regen volt valami feketelista, es ha X cuccod volt, akkor tudta a rendszer
> hogy az szar, es automatikusan tett valamit
> ezt az ide cache-t is lehetne valami fekete listaval kezelni szerintem
> ami azert jobb megoldas, mint egyszeruen kikapcsolni, mert van szar ide-s
> vinyo is. a vinyok mekkora resze lehet szar ? arrol nem beszelve, hogy gondolom
> ha X gyarto kihoz egy gyenge sorozatot, akkor majd 6 honap mulva kihoz
> egy jobbat.

Erről Soren Schmidt-tel, az ATA driver mágusával kellene diskurálni.  Elég
aktív a srác és alapjában véve jól csinálja a dolgokat (**ok, nem kell
jönni a dumával, hogy kinek a milyen CDROMja még mindig hogy nem játssza
le a zenéket**).  Az IDE vinyós ügyet elég jól karbantartja, fejlesztgeti
és elég sok vincsit letesztelt, mielőtt meghozta ezt a döntést.  A vinyók
*nagy része* csinált marhaságokat nagy írási terhelés alatt.  Nem arról
van szó, hogy gyenge sorozat, sajnos.  Az van, hogy a softupdatest
szeretnék olyan szintre felhozni, hogy tényleg nagyon korrekt legyen.  Az
meg azzal ügyeskedik, hogy úgy számol, ha ő kiad valamit írásra, akkor azt
a diszk azonnal ki is írja.  Ha nem írodik ki és bejön egy crash, akkor
nagy gáz lehet, mert a softupdates tényleg hajlamos nagyon keveseket írni
a diszkre.  Itt elismerték a jelenlegi ATA driver hibáit is, ugyanis lenne
lehetőség arra, hogy jobban kihegyezzék az egyes diszkekhez, stb.  (Tehát
az írási cache kikapcsolása hivatalosan ideiglenes.)  Ez még a jövő
zenéje.  Most viszont meg kellett lépni ezt a dolgot.  Megjegyzem hasonló
probléma fennáll a hálózati drivereknél is, ha valaki normális priority
queueinget vagy hasonlót akar megvalósítani: a hálókártya ott tartja
magában a csomagokat, amíg el nem ér egy bizonyos szintet a queue.  Meg
ilyenek.  És egy csomó driver nincs felkészítve arra, hogy ezzel tudjon
kezdeni valamit.



> vagy legalabb egy olyan listat csinalnanak, ahol a tuti jok lennenek
> es azokat automatikusan engedelyezne...
> mikor lesz journaling filerendszerunk ?
> es 1ebkent is.

Journaling FS mostanában nem, bár nagyon noszogatja mindenki a
fejlesztőket...

Viszont kezd előtérbe kerülni, hogy a softupdates-szel jobban járhat az
ember, mint egy journaling FS-sel...  az UFS nagyon bevált, jó, stabil,
stb, softupdates-szel gyors is, és az fsck biztonságos.  Tehát mondom,
most abba az irányba húz a project, hogy erre kell ráerősíteni...
-CURRENT-ben már van background fsck, ami a hosszú fsck-kat illeti, és az
is tény, hogy ha valaki normálisan tuningolja a newfs paramétereket, akkor
nem tart sokáig az fsck amúgy sem...




                                         ______  o _. __
                                         / / / (_(_(__(_)  @ bsd.hu