Re: [linux_var] PATCH KERNEL LINUX

scegliere dove mettere i file.

Illustro brevemente il mio problema attuale:

devo processare un certo numero di flussi video, diciamo una quarantina,

che arrivano come stream rtsp, in formato h.264 a 25 fps.

Le immagini del flusso devono essere elaborate da una serie di moduli software.

Questi flussi venivano inizialmente elaborati da una prima applicazione che li salvava in

singole immagini jpg per le successive elaborazioni.

Questa applicazione non scritta da noi non aveva nessun meccanismo di switch tra cartelle

e quindi scriveva nella stessa cartella 25*3600 immagini jpg ogni ora per ogni cartella.

Le immagini venivano prese da una successiva applicazione, elaborate con un algoritmo veloce,

e una parte veniva scartata, mentre un'altra parte veniva spostata in una seconda

cartella per successive elaborazioni.

Un terzo modulo effettuava l'elaborazione + pesante, cancellando la maggior parte delle immagini

e salvandone solo una minima parte.

Quindi riassumendo si tratta di elaborare 90.000 immagini per ora per canale, poi purtroppo

ogni tanto qualche processo si bloccava e di conseguenza si iniziavano ad accumulare

file nella directory corrispondente.

Se questo succedeva nel fine settimana vi potete fare 2 conti di quanti file si venivano ad

Adesso è stato riscritto il modulo 1 facendo wrapping delle librerie avcodec di ffmpeg

e fuso insieme con il modulo 2, quindi abbiamo un po' piu' di controllo sul

flusso di immagini, ma comunque la situazione è sempre critica.

La riflessione "filosofica" è che senza dubbio c'è un problema di scalabilità nella gestione delle directory in Linux,

(credo comune a tutti i S.O.) ed in particolare quando si supera le dimensioni di un set di gruppi di blocchi.

Un'altra riflessione riguarda la possibilità di avere un controllo sul contenuto dei dischi quando questi sono

di dimensioni notevoli, il famigerato "du veloce" che ritengo sia un problema sentito da sempre.

Credo sia "fondamentale" cercare di capire "perché" il du è immensamente lento.

Dipende dal fatto che le informazioni necessarie sono sparse in molte zone del disco, e che col du classico

vengono ripetutamente lette, facendo spostare le testine un po quà ed un po là.

Finché il sistema ha abbastanza Ram da tenere in cache una buona parte delle informazioni necessarie

si riesce ad avere risultati accettabili, ma con le partizioni di grandi dimensioni diventa veramente arduo.

Prendiamo ad esempio una partizione da 1TB, questa viene normalmente formattata in blocchi da 4KB,

i blocchi vengono raggruppati in gruppi da 32K blocchi (128 MB), proprio per motivi di performance la tabella degli inode viene

suddivisa in tantissime parti ognuna in un gruppo di blocchi, tipicamente 32K inode per ogni blocco.

Quindi il nostro disco da 1TB viene suddiviso in 8.000 zone da 128 MB.

In realtà sempre per problemi di performance i gruppi di blocchi vengono a loro volta raccolti (packed) insieme a

formare un virtual-block-group più grande, in modo da ridurre lo spezzettamento della tabella degli inode (opzione -G della mkfs.ext4)

Devo provare anche a ridurre la dimensione degli inode, in quanto non usiamo xattr acl etc...

Il giorno 06 aprile 2011 14:56, Diego Roversi <diegor@tiscali.it> ha scritto:

On Mon, Apr 04, 2011 at 04:22:46PM +0200, Giovanni Orlandi wrote:

> Banalmente sono la cancellazione diretta di una directory con milioni di
> files,
> adesso sto lavorando con dischi in RAID di diversi TERA e capita che alcune
> directory si "riempiano" di milioni di FILE
> poi per cancellare il tutto con il classico "rm -r" occorrono *ALCUNI
> GIORNI *nonostante dei server Dual Xeon che
> vantano 24 processori (12 core * 2 con hypertrading)
> E naturalmente in quel lasso di tempo il server diventa inservibile con
> iostat al 100% sul disco in questione.

Il problema di base e' che una directory e' una struttura sequenziale, per
cui c'e' il rischio che per cancellare un file, si deve scandire tutta la
directory per trovare il file da cancellare. In realta' ci sono gia' una
serie di "ottimizzazioni" che vengono fatte dal kernel per evitare il
problema (vedi opzione dir_index per ext3 e ext4), ma credo che con questi
numeri diventa' un paliativo. Non solo sempre ext2 e successivi, cerca di
allocare i file di una stessa directory nello stesso gruppo, in modo da
ridurre i seek time per passare da un file al successivo, ma se il 99.9% dei
file sta nella stessa cartella, non e' in grado di farlo.

Di solito, dato che e' un problema abbastanza noto, la soluzione canonica e' di
sfruttare il fatto che e' possibile creare una struttura ad albero di
directory innestate. E poi si usa un sistema di hashing per decidere in che
cartella mettere i file.

Esempio banale, mettiamo che i file sono tutti numerati: foo000001.txt,
foo000002.txt e cosi' via. A questo punto si puo' creare un alberatura di
questo tipo:

cartella-+0000-00
| +01
| +02
. ...
+0100-00
+01
+02

E il file foo123456.txt verra' sempre salvato nella sottocartella 1200/34.
In questo modo le singole directory rimangono piu' compatte e non c'e' il
rischio che si sparpaglino in giro.

In verita' l'approccio canonico era del tipo cartella/12/34/file123456.txt,
ho messo 1200 nella speranza che fosse piu' chiara ^^

Questo tipo di approccio era particolarmente popolare agli albori di unix,
quando le directory non erano indicizzate, ma ancora adesso sembra dare un
buon speedup, rispetto all'unica cartella con milioni di file.

Ovviamente quanti file mettere in ciascuna cartella dipende dal sistema, ma
di solito i numeri sono nell'ordine di alcune centinaia per cartella. Al
limite mille.

Saluti,
Diego Roversi.

--

Per cancellare l'iscrizione: <talking-unsubscribe at ml.linuxvar.it>
Archivi web e configurazione: http://ml.linuxvar.it/ml/

--
-----------------------------------------------------------------------------------------
Luca 18,5 : "Poiché questa vedova è così molesta le farò giustizia, perché non venga continuamente a importunarmi".
Neemia 8,10 : "...questo giorno è consacrato al nostro Signore; non siate tristi; perché la gioia del Signore è la vostra forza".
GSM 345.6050488 / 327.0547392 / 392.0698126 - Fax 06.62204735