5 risposte a “Il prossimo Kernel Linux, il 6.13, avrà migliorie su NFS, supporto audio hardware e vedrà sparire definitivamente ReiserFS”

1. 

   JustATiredMan

   2 Dicembre 2024

   Beh, NFS sarà obsoleto quanto volete, ma ancora oggi, lato enterprise è ancora ben usato, e le performances che ottiene sono di più che buon livello, salvo che non si vada a lavorare con iscsi o fc, che poi è una roba diversa, e che anche li poi, in certe configurazioni, a fronte di una maggiore complessità di implementazione, non si guadagnano chissà quali prestazioni.
   Per quanto riguarda ReiserFS, anni fà lo usavo come fs per i mail server, ed è un peccato sia finito in questo modo ma tant'è… purtroppo le vicende personali del creatore ne hanno decretato la morte, e fatto passare in secondo piano, anche le buone idee con cui nasceva.

2. 

   Giok

   2 Dicembre 2024

   Piccolo refuso: "Infinele"

3. 

   Raoul Scarazzini

   2 Dicembre 2024

   Grazie, corretto.

4. 

   Raoul Scarazzini

   2 Dicembre 2024

   Ma le performance di Reiser comparate, per dire, a XFS, in usi su ambienti come quelli che descrivi (posta, quindi tantissimi micro file) erano così determinanti?

5. 

   JustATiredMan

   3 Dicembre 2024

   Beh… diciamo che bisogna anche contestualizzare il periodo in cui lo usavo. Stiamo parlando del 2000 o giù di lì. In quel periodo Linux girava col kernel 2.4 e gli altri os erano windows 98/ME/NT/2000, Mac Os System 8 e 9 (il classic, non l'osx). Per lo più gli storages erano hdd in raid scsi parallelo, magari con su das esterno. FC e altre robe stile san, erano costosissime e fuori portata. Le cpu erano Pentium 3/4 ed i server tipo erano 1u con 1 Gb di ram quando andava bene. La virtualizzazione c'era, ma era roba nuova. Vmware esx 1.x arrivava nel 2001, ma per quelli come me, era fantascienza.
   In quegli anni i server mail giravano in bare metal, e magari qualcuno ci faceva girare anche il news server. ReiserFS, a patto di pagare uno scampolo di prestazioni, aveva un opzione interessante, non attiva di default, ma da usare nel mount, che era l'inclusione di più files nello stesso blocco, il che ne riduceva la frammentazione interna, utile appunto nelle maildir e newsdir. Inoltre gestiva quantità enormi (per l'epoca) di files e directory senza battere ciglio e in maniera velocissima. Fare un ls -l di una maildir o newsdir contenente anche 50/100 mila files, era un lampo. Fare la stessa cosa con ext2/ext3/xfs, dopo aver lanciato l' ls, dovevi aspettare un paio di secondi prima di veder scorrere la lista. E in un periodo dove ext2 la faceva da padrone, ext3 era il concorrente ma si portava ancora dietro alcuni limiti di ext2, il ReiserFS sembrava un fulmine. XFS era sicuramente l'alternativa già allora, ma consumava più ram, e comunque nelle grandi quantità di files, performava peggio. C'è anche da ricordare che l' Xfs che usiamo oggi, non è lo stesso di allora. Quello che usiamo oggi è stato molto ottimizzato (e ovviamente lo facciamo girare in ben altro hardware). Un altro ambito in cui Reiser si prestava bene, era anche nei file server dove si faceva girare il Netatalk, il protocollo afp di file sharing di Mac Os, prima che venisse preferito il samba (comunque afp è ancora oggi supportato dal mac os, mi pare siamo arrivati alla 3.1 di afp). Apple ha sempre avuto il problema dei resource files da gestire, quelli che dalla stessa sharing da windows vediamo iniziare con ._ che contengono i metadati, il bitmap dell'icona etc. Ogni file che si crei su una sharing condivisa con un Mac, te ne ritrovi uno di pochi kbyte che inizia ._ e questo ovviamente, significa raddoppiare il numero di files in ogni directory. Ripeto, oggi, con l'hardware che ci ritroviamo, per qualsiasi fs si vada ad usare, questi problemi sono per lo più parte del folklore di vecchi sistemisti, ma all'epoca, in determinate situazioni, poteva rappresentare un collo di bottiglia, e l'uso di ReiserFS aiutava.