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

[Marco Ermini]

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, e
continuo a ripeterti che l'hdparm fatto su delle partizioni non ha
senso.

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


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

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

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
:-)


[...]
> Ah, non ci avevo neanche pensato, ma allora se i risultati erano
> relativi solo all'accesso fisico al disco senza l'astrazione
> di accedere ai files, a maggior ragione la spiegazione dovrebbe
> essere quella che avevo dato.

No, la spiegazione è che il test non ha alcun senso, punto :-)


[...]
> 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? :-)


> (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. Per esempio se
usi il BSD-style il tipo di tabella di partizioni è diversa 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 :-)


> ciao
> Pietro


Ciao
-- 
Marco Ermini
Dubium sapientiae initium. (Descartes)
root@human # mount -t life -o ro /dev/dna /genetic/research
http://www.markoer.org/ - https://www.linkedin.com/in/marcoermini