E / S de disco de bajo nivel en Linux

¿Puede un progtwig de nivel de usuario hacer un nivel de página o bloquear la E / S de nivel en las SSD?

He examinado los dispositivos de disco, pero no estoy seguro si proporcionan esto, ya que solo funcionan si la partición tiene un sistema de files.

ACTUALIZACIÓN # 1

Quiero escribir un almacén de valores key de alto performance para las SSD, por lo que necesito alguna forma de acceder a bajo nivel (incluyendo leer, escribir y borrar).

Sé que mi enfoque debe ser de nivel kernel, pero antes de eso quiero probarlo en el espacio de usuario (evitando la complejidad de aprender progtwigción a nivel kernel).

Solutions Collecting From Web of "E / S de disco de bajo nivel en Linux"

Puede hacer E / S de disco de bajo nivel en cualquier tipo de almacenamiento a través del dispositivo de bloque , algo así como /dev/sda (para todo un disco) o /dev/sda1 (para una partición) en Linux. Esto pasa por alto completamente el sistema de files.

Si implementa su propio almacén de key-valor, le garantizo que lo que se le ocurrirá será mucho más lento y más lento que los filesystems y bases de datos escritos por profesionales. Un mecanismo de almacenamiento eficiente necesita tener en count aspectos como el almacenamiento en caching, las escrituras simultáneas, la resistencia a fallas de energía, etc. ¡Esto es muy difícil!

No creo que la optimization de E / S en ese nivel pueda lograrse mediante un progtwig de usuario (y mucho less la mecánica de optimization necesaria para hacerlo). Así que mi enfoque sería optimizar el process directamente en la aplicación mediante la implementación de algo así como una queue que vacía su contenido al resultado deseado una vez que ha superado un umbral de datos establecido. Un pseudo-código podría verse así:

 MAX_OBJS=100 M[100]=new M[100] function saveObj(obj) { if (M.size > MAX_OBJS-1) { outputStream.appendArrayToBinary(M) M = new M[100] } M.add(obj) } while (true) { saveObj( new Obj ) } 

Como puede ver, tendría un buffer de 100 objects. Tan pronto como se intenta salvar el object 101, escribe en el disco los otros 100 y borra el búfer para dejar espacio para otros 100 objects. Por supuesto, puede implementar técnicas más complejas, como realizar la escritura en otro subprocess y bloquear el arreglo para que otros objects no se agreguen hasta que se termine de escribir los objects en el disco y borrar el búfer. O algo así.

Ya te indiqué en otra cuestión tuya por qué debes abstenerte de un enfoque a nivel kernel.

Antes de comprometerse en tal empeño, se deben aclarar algunos puntos:

"Alto performance" no es una propiedad única para todos.

La optimization debe realizarse para casos específicos y solo cuando haya detectado el cuello de botella principal.

Debería hacerse las siguientes preguntas:

  • ¿He evaluado las implementaciones principales actuales de los sistemas de almacenamiento key-valor? ¿Si no, porque no?
  • Si lo hiciera, ¿por qué no son aptos para mi caso de uso? ¿He realizado evaluaciones comparativas exhaustivas y testings? ¿He rastreado el cuello de botella principal? ¿Puedo arreglarlo en las implementaciones actuales de vanguardia? Si no, ¿por qué creo que puedo solucionarlo en mi propia implementación?
  • ¿Cuáles son mis requisitos exactos de performance? ¿He definido "performance" y he encontrado forms de medirlo? ¿Alto performance durante las operaciones de almacenamiento? Alto performance durante las operaciones de recuperación? ¿Alto performance bajo alta carga debido a la gran cantidad de conexiones de clientes?

Una vez que tenga una idea clara de lo que quiere lograr exactamente , y una vez que haya rechazado el software actual de última generación, solo entonces debería comenzar a explorar posibles estrategias de implementación.

Kernel es el último lugar al que quieres tocar. Especialmente si no tiene experiencia previa en el desarrollo del kernel. La mayoría de los subsistemas del kernel están altamente optimizados a través de processs que tomaron años de testings y desarrollo por ingenieros altamente calificados.

Mi consejo sería considerar la optimization a través de una combinación de escritura en antememory, almacenamiento en caching inteligente y escritura diferida. Sería una buena idea familiarizarse con algorithms populares de almacenamiento en caching, enfoques de balanceo de carga y observar cómo funcionan las cosas bajo el sistema de files moderno (como readahead , Write policies , LRU ), aunque estos no estén directamente relacionados con su problema , pero ayuda saber cómo las personas resolvieron problemas de performance en dominios similares. Por supuesto, esto no pretende ser un consejo para volver a implementar estas funciones en su aplicación, ya que el sistema de files ya las ha implementado mejor; en la mayoría de los casos, esto dañará el performance de su aplicación en lugar de mejorarla.