[++++SPAM++++] Re: [Tech] velocità del disco diverse tra NTFS e ReiserFS

[Simone Piccardi]

Marco Ermini ha scritto:
> On 4/27/07, Pietro Poggi <pietro.poggi@unifi.it> wrote:
> [...]
>> Io parlavo del transfer rate interno, cioe' di dati che non
>> sono in cache, se quando vado a leggere un dato ho la fortuna
>> che sia in cache bene, se non c'e' dovra' andare fisicamente
>> a leggerlo sul disco, non capisco bene la tua obiezione.
> 
> L'obiezione è molto semplice: NON PUOI SAPERE quanto ci metterà il
> disco a prendere il tuo dato.
> 
Per prendere il dato di cui parla Pietro (cioe` la velocita` di lettura
sequenziale dal disco) hdparm e` lo strumento giusto e te lo fa sapere.
Se poi cerchi altri dati, che non c'entrano nulla con i risultati
mandati da Valerio, e` ovvio che non lo e`.

Ed il motivo della differenze del test di Valerio (che non c'entra nulla
con le prestazioni del filesistem) e` appunto quello spiegato da Pietro.

> 
>> Riguardo a hdparm io no ho mica sostenuto che e' il migliore
>> test da fare, davo solo una spiegazione alla domanda che ha iniziato
>> il thread che riguardava la differenza tra le velocita' di accesso
>> ad un filesystem NTFS e uno ReiserFS e dicevo che i filesystem
>> non c'entravano ma era solo una cosa riguardante la posizione fisica
>> dei dati sul disco, e continuo a pensare che quella era la spiegazione,
>> e mi sembra anche una spiegazione semplice.
> 
> Ed è una spiegazione che confonde l'accesso FISICO con il LOGICO al
> disco, semplice.
> 
> hdparm non è un pessimo tool, è il tool sbagliato. Lo stai usando per
> testare una partizione, quando lui testa solo dischi. Non è difficile
> da capire :-)
> 
No non confonde proprio nulla. Ti dice semplicemente come stanno le
cose. hdparm non fa una misura di accesso logico, ma fisico e quando
misura una velocita` di lettura sequenziale puo` benissimo farlo a
livello di partizioni (francamente quello che e` difficile da capire e`
per quale motivo non dovrebbe essere in grado di farlo).

Per cui se lo usi su partizioni diverse di uno stesso disco leggera` da
quelle, che stando su posizioni fisiche diverse (interne o esterne) con
una velocita' di lettura sequenziale diversa, daranno risultati diversi.

E lasciamo perdere LVM, il raid, l'allocazione dei dati sul disco ed il
resto, che evidentemente con il test di Valerio non c'entrano nulla.


>> Comunque dobbiamo intenderci di cosa parliamo perche' tu mi parli
>> di ambienti con risorse elevate (array di dischi ecc.), io mi riferivo
>> a desktop casalingo o usato come workstation personale, in poche
>> parole mi riferivo a un singolo disco, senza far entrare in gioco
>> scenari piu' complicati. Parlando del range di cilindri del disco
>> dove sta una partizione e' chiaro che parlavo di un singolo disco,
>> se mettiamo di mezzo un raid con striping ecc. allora stiamo
>> cambiando argomento e certamente e' molto piu' complicato di quello che
>> dicevo io.
> 
> Ho risposto a quello che hai detto tu, ovvero che è "poco noto" che ci
> sono grosse differenze nell'accesso a settori diversi dei dischi e che
> "bisognerebbe tenerne di conto". Io ti rispondo che è poco noto perché
> è praticamente inutile saperlo e ti ho dato una giustificazione.
> 
> E il volume manager è installato di default in qualsiasi installazione
> di Ubuntu casalinga del cavolo... senza dischi RAID o altro...

Sul perche' sia poco noto propendo per l'ignoranza, sul fatto di quanto
sia utile saperlo... beh nel caso serviva a rispondere a Valerio, come
e` stato fatto, che le prestazioni dei filesystem non c'entrano nulla, e
che le differenze che trovava con hdparm erano dovute ad altro.

>> Magari hdparm non e' la cosa migliore, ma appunto se parliamo di singolo
>> disco, una partizione fisicamente sta tra un raggio
>> minimo ed uno massimo (a meno che non ci sia un remapping logico dei
>> settori
>> nell'elettronica di controllo del disco, ma non sembra comune).
>> Senza pretendere di essere uno specialista, ho letto un po' su queste
>> cose e questo e' quello che ho sempre trovato, se mi sai indicare
>> una fonte che mi spiega perche' non e' cosi', sono sempre
>> contento di imparare.
> 
> Sono talmente stanco di ripeterlo :-) non capisco cosa ci sia di così
> complesso... si sta confondendo il test di un filesystem con quello di
> un accesso fisico a un disco con quello di una partizione... quando si
> legge qualcosa bisogna contestualizzarlo e capirlo, non dico altro :-)

Ma di quale test di filesystem stai parlando? E' stato chiesto: ho
questi risultati di hdparm, perche` reiser fa schifo? la risposta e`
stata: il filesystem non c'entra nulla ed il risultato di hdparm dipende
da altro.

Mi pare che l'unico che sta confondendo il test delle prestazioni di un
filesystem con la misura della velocita` di lettura sequenziale eseguita
con hdparm (che con i filesystem non c'entra nulla) sei tu, che a quanto
pare non sei in grado di concepire il fatto che hdparm sia in grado di
eseguire una misura della velocita` di lettura sequenziale anche sulla
singola partizione.

In ogni caso prima di criticare gli altri per le loro risposte, tirando
fuori cose che non c'entrano nulla, magari sarebbe meglio leggere e
capire a cosa rispondono.


> [...]
>> Io non sostengo che si DEVONO fare queste considerazioni
>> (sulla velocita' di accesso alle varie partizioni) partizionando
>> un disco, dico solo che se uno ha voglia di farle sta facendo
>> una cosa che ha un senso !
> 
> No, non ce l'ha.

Si che ce l'ha, visto che la velocita` di lettura sequenziale dei dati
e` diversa a seconda di quale porzione fisica del disco stai usando (per
cui quando operi a livello di partizioni lo vedi), ed una maggiore
velocita` di lettura e` comunque un fattore positivo per qualunque
filesystem.

Se poi non te ne frega nulla perche' ti fa comodo usare LVM, hai
macchine strafiche con RAID e tanti dischi ecc. per cui alla fine di
questo tipo di differenze vanno perse nei mille fattori che si
incrociano per cui non te ne accorgi neanche va anche bene. Ma se devi
recuperare una vecchia macchina, saperlo puo` essere un fattore in piu`
per una scelta consapevole.

>> E volevo solo dare una spiegazione
>> ai risultati di hdparm del mail che ha iniziato il thread
>> e credo che la mia spiegazione sia azzeccata, tutto qui.
> 
> Io credo che sia chiaro come il sole che se usi uno strumento
> concepito per accedere fisicamente al disco per misurare la velocità
> di un filesystem, stai cannando completamente lo strumento di
> misurazione e confondendo l'oggetto realmente misurato.
Di nuovo, se c'e` qualcuno che fa confusione fra misurazione delle
prestazioni di un filesistem e risultati di hdparm quello non e` stato
certo Pietro, che ha semplicemente spiegato come mai i due risultati di
hdparm erano diversi. Che Pietro stesse parlando di hdparm come di uno
strumento per misurare le prestazioni di un filesystem sei tu a dirlo,
non lui.


> Ti puoi mettere a leggiucchiare tutte le spiegazioni astruse che vuoi
> su Internet, ma stai comunque usando un tool che probabilmente IGNORA
> la differenza tra hda1 e hda2 dal momento che sono lo stesso disco,
> per misurare la velocità di un filesystem, fregandotene del fatto che
> per misurare le performance di un filesystem devi considerare se stai
> facendo una lettura o una scrittura, che tipo di dato stai accedendo,
> se esistono dei conflitti sul locking, ecc. ecc.
> 
E allora secondo te che non hai leggiucchiato su internet e che
evidentemente conosci la risposta, perche' mai hdparm avrebbe trovato
diverse velocita` su diverse partizioni di uno stesso disco?
Lui ha dato dei riferimenti precisi alle sue affermazioni, gradirei
vedere i tuoi.

Inoltre qui l'unico che sta facendo panegirici sulla misurazione delle
prestazioni dei filesystem con hparm (si, lo sappiamo benissimo che non
serve a quello) sei tu. Pietro non ha sostenuto che hdparm misura le
prestazioni dei filesystem, ha solo spiegato perche' puo` dare risultati
diversi su due partizioni diverse sullo stesso disco.

>> Comunque si fa per chiacchierare :-)
>> (ed ho chiacchierato tanto, direi, speriamo che qualcuno resista
>> a leggere fino a qui...)
> 
> Si fa per chiaccherare ma è una questione di metodo e di capire cosa
> si sta facendo :-)
Si, su questo siamo proprio d'accordo.

Ciao
Simone