threads translator best practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi guys,

I have been pondering about the threads translator and where to put it, at the top just below the physical disk or at the buttom as the exporter..

On the server, what happens if all other translators like iocache, locks and writebehind are threaded - do I have to calculate the memory consumption times the count of threads, and if so - what about object uniqueness, if one thread is cached but the other dont know about it ?

Maybe, there is no need to to use the threads translator just above protocol level. If the server only has one CPU, but it would still make sense to use it before the physical disk so that scsi queueing could be used properly to get the most IOPS out of them..

Any idea in using the threads at both protocol and disk level maybe ?

From what I have understood, on the server-side - put the iothreads just after locks. On the client side, just before the protocol...

A lot of questions, maybe you can just supply me with a best practice when using the non-blocking translator ?

Best regards,

Thomas.




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux