Newsgroup: it.comp.os.linux.sys
Titolo: [HARDCORE SAMBA] - Per soli duri

Il problema è servire file (archivio storico in sola lettura) via SMB alla
massima velocità possibile.
I file ora sono circa 10.000 ma entro la fine dell'anno si presume di
arrivare a circa 20.000;
il tasso di crescita si assesterà sui 100/mese dopo questo periodo di
start-up.
Lo spazio on-line del file server sarà 110GB ~
Sono file di grandezza che varia tra 1MB e 10MB (punte a 100MB) di tipo
sequenziale (foto).
L'organizzazione del file system che li conterrà è abbastanza libera ed è
possbile decidere quanti file per directory, quanti livelli di directory
etc.
Il numero di client che accederà contemporaneamente per leggere (e basta!) i
dati è stato quantificato in 50 per diventare al massimo 100.
I client sono tutti Windows 98 e 2000.
L'hardware messo a dispozione a grandi linee è:
CPU PIII 350@466 stabilissimo me lo hanno giurato ;-)
MB ....non saprei ma dovrebbe supportare ATA 100, 66 comeminimo cmq
RAM 128MB 133MB
2 x HD 60GB ATA 100 Quantum (sperando che non soffrano l'overclock)
2 x NIC 3c905BTX 3COM
Ho pensato ad una configurazione in RAID 0 con i due HDD su ciascun canale
IDE (opportunamente tunati con hdparm); ho dei bubbi sui limiti di ext2 che
mi spingono ad usare reiserfs o ext3 o jfs.
Uso da tempo in produzione reiserfs ma non ho dati su file di quella
grandezza e quindi sono nel dubbio.
Avendo a disposizione due NIC è possibile adottare uno schema tipo
round-robin ?
Mi verrebbe in mente di inserire due entry nel WINS (NT4 SP6a) ma non sò se
è corretto.
Aspetto suggerimenti su:
tipo di fs da adottare con eventuali parametri
organizzazione del fs
load balancing sulle due NIC
tuning di samba
[global]
	log level = 1
	socket options = TCP_NODELAY IPTOS_LOWDELAY
	read raw = yes
	write raw = yes
oplocks = yes
	max xmit = 65535
	dead time = 15
	getwd cache = yes
	lpq cache = 30
[share]
	veto oplock files = this/that/theotherfile
Vorrei far fare a linux con samba una figiura dignitosa che mi permetta più
avanti di proporre un hardware più consono su cui poi potranno decidere se
conservare il pinguino o mettere Windows 2000 server per lo stesso uso...
Grazie, siete fantastici.
Ciao

 tuning di samba
Io aggiungerei più ram, se possibile, verrebbe tutta usata come
buffer.  I dischi SCSI sono la mossa successiva, budget permettendo.
Visto che i dati sono in sola lettura, monterei la share come read
only e disabiliterei il locking, può darsi serva anche questo.
Altre considerazioni: raid software e ATA100 possono migliorare le
prestazioni di lettura dei dischi, ma consumano risorse di cpu e
memoria.  Memoria che potrebbe essere usata come cache.  Da vedere se
una configurazione più "liscia" è veramente inferiore, nel tuo caso.
Ritengo comunque che le prestazioni saranno più che decenti, e
sicuramente migliori di Win2000 a parità di macchina.  Non vedo la
necessità di impelagarsi nell'overclock su macchine di produzione..
        Ciao
                Guido

 impelagarsi nell'overclock su macchine di produzione..
Mah, per quanto riguarda la condivisione via SMB, credo che Win2000 sia
abbastanza piu' veloce di Samba. Ovviamente ci sono un sacco di altri fattori
da tenere di conto: di sicuro una macchina Linux e' piu' stabile se cominci a
smanettarci sopra....
ciao ciao ciao
-- 
Marco Ermini
http://www.markoer.org
 - ICQ # 50825709
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.      -- Jeremy S. Anderson

> mi spingono ad usare reiserfs o ext3 o jfs.
Visto che lo share e' in ro va bene anche ext2, specie se non esageri con il
numero di file nella directory. Se vuoi un raid0 assicurati un backup
costante e recente. Se vuoi un raid 0 con dischi ide fallo con un controller
hw, hanno un costo ragionevolissimo.
--
  	Giuseppe "Cowo" Corbelli  -->>  Riding on Linux-2.2.18
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! 3rd Law of Computing: Anything that can go wr
		fortune: Segmentation violation -- Core dumped !>-

 smanettarci sopra....
Davvero?  Win2000 "abbastanza più veloce"?  Devono aver fatto passi da
gigante.  Anche senza tener conto (il che non è poco) che Win2000
spreca un'iradiddio in più di risorse in cose che hanno poco a che
vedere con l'attività di file-serving, e che in paragone Linux avrebbe una
quantità di memoria in più, disponibile per i buffer, resta il fatto
che, rispetto a NT, devono aver fatto miglioramenti inaspettati.
O no?
Mi piacerebbe vedere qualche benchmark in situazioni reali.
Di sicuro NT non è "abbastanza più veloce" di Samba.
        Ciao
                Guido 

Grazie a tutti vi farň sapere i risultati di bench fatti in casa per la
situazione che vi ho descritto prima (si ho deciso di installare windows
2000 per vedere che effetto fa).

 Di sicuro NT non è "abbastanza più veloce" di Samba.
Diciamo pure sostanzialmente piu' lento. La verifica sul campo e'
evidente. Mi incuriosisce (oltreche stupire) molto sentire che invece
2000 sarebbe piu' veloce. Si puo' saperne di piu'? Sono stati fatti dei
benchmarks da qualcuno in proposito?
-- 
Saluti - Marco Coli

 Di sicuro NT non č "abbastanza piů veloce" di Samba.
]zac[
Una cosa particolare e' che se si accede da winXXXX ai file condivisi con
samba usando direttamente il percorso di rete (\\pc_linux\wa\......) ogni
volta impiega 1-2 secondi di preparazione (lo si nota molto facendo click
col tasto destro per vedere le proprieta' di un file), invece se si accede
agli stessi file attraverso una unita' di rete (g:\wa\......) il tempo di
preparazione si azzera.
Credo che sia dovuto al fatto che win ogni volta genera una nuova
connessione quando si usa il percorso di rete.
Questo problema non si presenta se i file risiedono su win9x o winNTxx.
Salve
            Dbg
P.S. ho fatto varie prove ma non ho trovato il modo di aggirare il problema

 2 x NIC 3c905BTX 3COM
Con quello che costano le CPU di quella fascia oggi l'idea di
averne una overcloccata è semplicemente ridicola.
Con quello che costa la RAM fanne comprare almeno 256Mb.
Ma, soprattutto, usa un sottosistema SCSI, per carità !!!!!
Ed usa un sistema di raffreddamento adeguato: ventole anche
davanti agli hard disk, ecc.

 P.S. ho fatto varie prove ma non ho trovato il modo di aggirare il problema
Curiosita': sui client hai solo il TCP/Ip o altri protocolli? Io
verificai che la presenza di altri protocolli puo' dilatare il tempo di
connessione.


C'era anche il NetBeui, ho lasciato solo in tcp/ip, ma, sigh, il problema
rimane tale e quale.
Salve
            Dbg
Marco Coli ha scritto nel messaggio


 rimane tale e quale.
Mi viene da pensare che ci sia qualcosa di strano nel smb.conf. Ho fatto
la riprova da me, e qui (client NT/98) non si notano differenze
accedendo alle share del server sia tramite unita' di rete che tramite
'sfogliamento' della rete. L'accesso e' immediato in entrambi i casi.


'sfogliamento' della rete. L'accesso e' immediato in entrambi i casi.
mmm non credo, anche se e' possibile che mi sia sfuggito qualcosa, o forse
e' samba 2.0.5a che ha questa caratteristica, o forse e' la versione di
win9x, vedro' di provare con altre versioni di linux/samba/win.
Le differenze si notano solo in casi particolari, per evidenziarle fai cosi:
- entra in una cartella condivisa con samba, con una decina di file, usando
risorse di rete di win
- fai click col tasto destro su un file e noterai che ci vogliono 2-3
secondi prima che compaia il menu (se passi da un file ad un'altro senza
nessuna pausa il menu' compare all'istante)

 nessuna pausa il menu' compare all'istante)
Non avevo mai effettuato questa prova. Ho provveduto a riprodurla ora,
ma forunatamente (!) non ho riprodotto il problema (nel senso che non ho
avuto attese). Ho usato NT pero'. A te lo fa anche con NT?


avuto attese). Ho usato NT pero'. A te lo fa anche con NT?
Il problema si presenta solo con i file condivisi con samba e usando il
percorso di rete (risorse di rete).
Il problema e' diventato pesante ed evidente quando ho spostato su Linux con
samba una documentazione html composta da numerosi file e di discrete
dimensioni, il link tra una sezione ed un'altra (quindi tra un file html e
un'altro) era diventato lentissimo.
P.S. la rete su cui lavoro e' mista, ha NT4x, Linux, client Win9x, le prove
sono fatte a parita' di condizioni.
Salve
                    Dbg