On Mer, 15 Gennaio 2014 15:43, Flavio Stanchina wrote:
> Roberto Resoli wrote:
...
> le barriers sono un overkill, si possono ottenere gli
>> stessi risultati, con molto minor impatto sulle prestazioni (il minimo
>> impatto). Per questo sono deprecate da vari anni; non ho ancora capito
>> comunque, in definitiva, quanto sia sicuro disabilitarle (cioè quanto
>> la
>> funzionalità sia stata migrata all'interno dei filesystem). Il fatto
>> però
>> che lo siano su pve 3.1 mi sembra abbastanza indicativo.
>
> Ah, interessante; dopo averti risposto ho seguito meglio i collegamenti
> che hai passato (ed i vari thread a cui portavano) ed ho capito che le
> barrier come originariamente implementate non dovrebbero più esserci, ma
> non ho capito come facciano ora a garantire la scrittura in ordine del
> journal e come sia in pratica implementata fsync().
Il tutto è spiegato abbastanza
bene nel famoso articolo "The end of block barriers":
"in the real world, barriers are implemented by simply draining the I/O
request queue prior to issuing the barrier operation, with some flush
operations thrown in to get the hardware to actually commit the data to
persistent media. Queue-drain operations will stall the device and kill
the parallelism needed for full performance; it's not surprising that the
use of barriers can be painful.
In their discussions of this problem, the storage and filesystem
developers have realized that the ordering semantics provided by
block-layer barriers are much stronger than necessary. Filesystems need to
ensure that certain requests are executed in a specific order, and they
need to ensure that specific requests have made it to the physical media
before starting others. Beyond that, though, filesystems need not concern
themselves with the ordering for most other requests, so the use of
barriers constrains the block layer more than is required. In general, it
was concluded, filesystems should concern themselves with ordering, since
that's where the information is, and not dump that problem into the block
layer. "
Inoltre, nello stesso articolo è linkato questo post:
"replace barriers with explicit flush / FUA usage "
http://lwn.net/Articles/400777/
nel commento si legge, tra l'altro "This series converts over all
filesystems to the new WRITE_FLUSH_FUA primitive that Tejun added. XFS,
btrfs, gfs2, reiserfs, ext3 and ext4
have passed extensive xfstests coverage with this, while ocfs2, nilfs2
and fat are unsupposed by xfstests and thus untested in this patch."
>
> Comunque per scrupolo ho fatto alcuni test sui due PVE con un solo disco
> SATA ed i risultati indicano abbastanza chiaramente che spegnere la
> cache in scrittura o abilitare le barrier sia ugualmente deleterio per
> le prestazioni.
Da quello che capisco le barrier non servono più, perchè il filesystem (e
gli strati md, dm , ecc eventuali al di sotto) si sono evoluti abbastanza
da non richiederle più.
Ovviamente disabilitare tout-court la cache in scrittura ha un effetto
ancora più deleterio sulle prestazioni, rispetto all'abilitazione delle
barrier con cache attiva.
C'è da notare che:
> * è il kernel 2.6.32 di PVE, mi aspetterei numeri diversi dai kernel
> odierni se è vero che il meccanismo è stato rivisto e migliorato;
Attenzione che il kernel è quello di redhat, con numerosi backporting
dalle versioni successive.
Da vari accenni in rete ho sentore che già questo kernel recepisca la
deprecazione delle barrier
(le famose patch originali di Tejun Heo: https://lkml.org/lkml/2010/9/3/199 )
> * i test sono stati fatti a macchine scariche, quindi c'erano solo le
> fsync di pveperf a far girare il disco: in una situazione reale, dove le
> fsync sono mescolate a scritture random, mi aspetto che le barrier
> abbiano un impatto minore rispetto a disabilitare completamente la
> cache.
E' così; ma perchè disabilitare la cache?
ciao,
rob
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org