[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [linux_var] PATCH KERNEL LINUX



Prima di passare allo sviluppo, non e' meglio valutare altri filesystems?

http://serverfault.com/questions/6711/filesystem-for-millions-of-small-files


Ciao
Walter

2011/4/8 Giovanni Orlandi <orlangio@gmail.com>:
> scusate, secondo voi posso partire da questo articolo o è troppo vecchio
>
> http://tldp.org/HOWTO/html_single/Implement-Sys-Call-Linux-2.6-i386/
> Gio
> 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
>

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