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

[Pietro Poggi]

On Thu, 26 Apr 2007, Marco Ermini wrote:

> On 4/16/07, Pietro Poggi <pietro.poggi@unifi.it> wrote:
> [...]
>>  Guarda che e' cosi', cerca un po' in rete test sugli hard disk
>>  e fai una ricerca su "internal transfer rate" e vedrai che il transfer
>>  rate interno (cioe' quello dalla superficie del disco al buffer
>>  prima dell'interfaccia) e' normale che dipenda anche in modo considerevole
>>  (tipo un fattore 2) dal range di tracce su cui si va a testare.
>
> Sì ma ignori il fatto che tutti gli accessi al disco sono cachati,

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.
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.

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.

> Potete continuare a lanciare hdparm fino all'infinito ma sono test
> inutili se li fate su una partizione :-)

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.

> [...]
>>  Lui aveva una differenza di 1.6 decimi di secondo, non secondi,
>>  ma quello che conta e' il rate MB/s ed un fattore 2 ci sta tutto.
>>  Microsecondi poi e' un po' pochino ;-)
>
> E perché mai dovrebbe essere pochino? mi sembra adeguato - è l'unità
> di misura che userei io. Se la usi per i socket di rete, figuriamoci
> per i dischi

Perche' guardando i dati dei dischi normalmente in commercio
la latenza media di accesso ai dati e' di vari millisecondi,
e ad es. il tempo che l'attuatore
ci mette a spostare le testine da una traccia e un'altra che non sia
proprio li' accanto e' appunto dell'ordine di 1-2 millisecondi.

>> >  Penso
>> >  siano ormai dieci anni che è considerato inutile stare a calcolare in
>> >  quale parte del disco mettere quale partizione...
>>
>>  Penso che ti sbagli, cioe' non e' inutile tecnicamente,
>>  piu' che altro direi che e' una cosa non molto nota e oltre
>>  a questo pochi ci pensano anche perche' e' difficile capire per l'uso che
> [...]
>
> E' un'operazione assolutamente inutile perché:
>
> - ormai tutti usano virtual volume managers di ogni tipo
> - i dischi vanno e vengono e soprattutto sono inseriti in sistemi di
> array per cui non puoi mai sapere in quale punto del disco il tuo dato
> è memorizzato

Ok, dicevo sopra che parliamo di cose diverse, io parlavo di 1 disco
sul proprio computer, di una singola persona che non ha mucchi
di dischi che vanno e vengono, mica sostenevo che uno puo' mettersi 
a calcolare dove stanno fisicamente i dati in un array.

> - i filesystem di per sè possono sbattere il tuo dato in un punto
> qualsiasi del disco seguendo la loro propria logica che è ormai
> complessa al livello di un database relazionale

Ma i filesyestem stanno dentro una partizione, se la partizione 
occupa una certa zona del disco, li' stanno i dati; ok i blocchi
che appartengono ad un file stanno dove vogliono dentro allo
spazio allocato per quella partizione, ma non e' che 
stanno fuori da li'.

> - come ho detto, anche se ci metti qualche decimo di secondo in più a
> raggiungere un dato in un settore specifico del disco, esso può
> comunque essere cachato dal controller o dal buffer stesso del disco

d'accordo, parlavo data transfer interno, quindi di dati non cachati.

> Quindi alla fine, più sali in complessità e più sei astratto dal layer
> fisico, e quindi qualsiasi calcolo tu faccia è pura accademia.
> Le tue considerazioni al massimo si applicano per un sistema
> "casalingo" ma allora non usare hdparm su una partizione, non ha senso

Si' io parlavo di un sistema "casalingo", che poi non e' cosi' 
riduttivo, nella mia esperienza si riferisce anche nei sistemi 
normalmente usati  per il calcolo scientifico ad es. da fisici
e ingegneri, che a parte centri di calcolo particolarmente evoluti,
sono piu' o meno sistemi casalinghi.

> [...]
>>  Giusto, ma probabilmente se lo fai su una partizione ti puo'
>>  servire appunto a vedere che il transfer rate di hdax e' funzione
>>  decrescente di x.
>
> Noooooo!... :-)
>
> Non ha senso, punto :-) hdparm testa le performance dell'accesso
> fisico al disco, quindi testare una partizione (che è una
> organizzazione LOGICA di un disco) è MEANINGLESS. Chiaro? :-)

Ma noooooo lo dico anche io :-)
La partizione a me sembra quasi piu' fisica che logica, e' proprio
poco piu' di un range di settori su cui stanno di dati, la 
parte logica e' il filesystem che organizza questi settori secondo la sua 
logica. L'informazione sulle partizioni per dischi partizionati
tipo DOS (cioe' quelli di cui parlo io, che penso siano quelli
che piu' o meno tutti qui hanno a casa, a parte i nuovi Mac su Intel
che usano EFI e partizioni GUID che non so come sono fatte) e' scritta
in pochi bytes, non c'e gran che di logica e' poco piu' dell'indicazione
di dove inizia e dove finisce.

>>  (se le partizioni sono numerate nell'ordine fisico in cui sono
>>  su disco, il che non e' detto perche' mi sembra che linux le
>>  numeri nell'ordine in cui compaiono nella tabella delle partizioni,
>>  che se uno ha fatto un po' di casino cancellando e creando partizioni
>>  non e' detto sia l'ordine fisico).
>
> Linux non fa alcuna numerazione :-) il modo in cui sono organizzate le
> partizioni dipende dal tipo di formattazione che usi.

Ma bisogna intenderci di cosa parliamo, allora saro' piu' preciso:
con linux intendevo linux su architettura x86 e dischi partizionati
nel modo tradizionale (Dos-style). Va bene ora ?
Se mi generalizzi tutto rispetto al contesto a cui mi riferisco
e' chiaro che c'e' sempre qualcosa che non va bene in quel che dico ... 
Ma e' normale che uno quando parla non dica tutto esplicitamente
ad es. se parlo del tempo che ci mette un oggetto a cadere
da una certa altezza, non mi metto a dire "sul pianeta Terra"
e a precisare la latitudine perche' l'accelerazione di gravita'
varia da un posto ad un altro ecc. :-)
Il modo in cui sono organizzati i dati dentro una partizione dipende
dal tipo di formattazione (intendendo formattazione=tipo di filesystem),
ma io parlavo di accesso "raw" ai dati (cioe' ad una partizione come
stream di bit). Il modo in cui linux numera (si' che le numera)
le partrizioni dipende solo da come e' partizionato (cioe' da cosa
c'e' scritto nei pochi bytes che costituiscono la tabella delle partizioni
nel MBR + quelli nelle tabelle negli extended boot records se ci sono
patizioni logiche).

> Per esempio se
> usi il BSD-style il tipo di tabella di partizioni è diversa

ok ok, ma stai generalizzando .... :-)

> e quindi
> non hai il problema tipico di quelle "IBM" style in cui devi avere per
> forza 4 primarie (e dalla quinta in poi si segue l'ordine delle
> secondarie). Ma questo non c'entra nulla con il topic :-)

Ma questo lo so ed e' proprio questo che c'entra col topic!
Cioe' le partizioni "IBM" style (quello che sopra chiamavo DOS-style)
individuano un range di tracce, cioe' una zona fisica dove stanno
i settori del filesystem (arbitrario) che verra' creato dentro quella
partizione. Se uno va a leggere un po' da una partizione e un po'
da un'altra le testine si dovranno spostare da una zona riservata
alla prima partizione a quella riservata alla seconda partizione,
e' una cosa fisica piu' che di organizzazione logica.

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 ! 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.
Comunque si fa per chiacchierare :-)
(ed ho chiacchierato tanto, direi, speriamo che qualcuno resista
a leggere fino a qui...)

ciao
Pietro