Elasticsearch 8 enables scaling the number of shards in a cluster beyond what has been possible. Built on a foundation of new benchmark infrastructure, these advances protect from regressions and provide rigorous data on how Elasticsearch can scale.

blog-elasticsearch-8-x2-throughput.png

blog-elasticsearch-8-drop-in-latency.png

elasticsearch improvement in total time taken

blog-elasticsearch-8-97-improvement-total-time-taken.png

elasticsearch copies of entire cluster state for new snapshot

blog-elasticsearch-copies-of-entire-cluster-state-for-new-snapshot.png

blog-elasticsearch-8-nightly-elastic-logs.png

blog-elasticsearch-8-wait-duration.png

blog-elasticsearch-8-wait-error-rate.png

illustration-elevate-arrow-1680x980.png

Benchmark-driven optimizations — How we pushed scalability to the next level in Elasticsearch 8

El nivel frío está a disposición del público en general en Elasticsearch 7.11. Conoce las pruebas que hicimos para asegurarnos de que esta característica está lista para que la implementes hoy.

El <a href="/guide/en/elasticsearch/reference/7.11/searchable-snapshots.html">nivel frío</a> de snapshots buscables, antes en versión beta en Elasticsearch 7.10, ahora está <a href="/es/blog/whats-new-elastic-7-11-0-searchable-snapshots-schema-on-read">a disposición del público en general en Elasticsearch 7.11</a>. Este nuevo nivel de datos reduce tu almacenamiento de cluster hasta en un 50 % en comparación con el nivel tibio y mantiene el mismo nivel de confiabilidad y redundancia que los niveles caliente y tibio. 

En este blog, veremos las situaciones que exploramos para asegurarnos de que el nivel frío funciona sin problemas a escala y destacaremos la importancia que le damos a la calidad y confiabilidad de nuestras soluciones.

<h2>Repaso del nivel frío</h2>
El nivel frío reduce los costos de cluster gracias a que mantiene solo los shards primarios en el almacenamiento local, lo que elimina la necesidad de shards de réplica y, en su lugar, depende de snapshots (que se mantienen en almacenes de objetos como AWS S3, Google Storage o Microsoft Azure Storage) para brindar la resistencia necesaria. El almacenamiento local básicamente actúa como una versión almacenada en memoria caché de los datos del snapshot en el repositorio.

En el caso de un nodo frío o almacenamiento local que comienzan a tener problemas, los snapshots buscables automáticamente recuperarán y volverán a equilibrar los shards en otros nodos.

En el caso de reinicios de <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-full">cluster completo</a> o <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-rolling">escalonados</a> (o reinicios del nodo), el almacenamiento local es persistente y los datos disponibles de forma local no volverán a descargarse de los snapshots, lo que minimiza el tiempo necesario para volver a un cluster en verde y evita costos de red innecesarios.

Para garantizar que todo esto funcione como se espera a escala, enfocamos nuestros esfuerzos de validación en tres escenarios, todos con lo siguiente:

<ul>
	<li>Cinco nodos de Elasticsearch (heap 16 G)</li>
	<li>Seis discos magnéticos de 2 TB en configuración de RAID-0</li>
	<li>Un snapshot de 5 TB de <a href="https://github.com/elastic/rally-eventdata-track#elasticlogs_bulk_source">datos de logging</a>, distribuido en 10 índices con cinco shards cada uno, fusionados por la fuerza a un solo segmento (la fusión por la fuerza optimiza el índice para el acceso de lectura y reduce la cantidad de archivos que deben restaurarse en caso de un evento de falla)</li>
</ul>
<h2>Situación 1: Reinicio de cluster completo</h2>
La primera situación que validamos fue la de <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-full">reinicios de cluster completo</a>. Para verificar esto, atravesamos los pasos siguientes:

<ol>
	<li>Montamos el snapshot buscable de 5 TB y esperamos a que la memoria caché local estuviera precalentada por completo (Fase 0).</li>
	<li>Ejecutamos un reinicio de cluster completo según las <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-full">pautas de reinicio de cluster completo</a>.</li>
	<li>Después de volver a habilitar la asignación, medimos cuánto demora el cluster para lo siguiente:
	<ol>
		<li style="list-style-type: lower-alpha;">Ponerse verde</li>
		<li style="list-style-type: lower-alpha;">Terminar todas las descargas en segundo plano para precalentar las memorias caché</li>
	</ol></li>
	<li>Nos aseguramos de que no hubiera ningún nuevo balanceo de shards adicional después del paso 3.</li>
</ol>
Gracias a la capa de persistencia que se incorporó recientemente en Elasticsearch 7.11, después de iniciar todos los nodos y volver a habilitar la asignación, el cluster se puso verde de inmediato y no se realizó ninguna descarga en segundo plano.

A continuación podemos ver el tráfico de red acumulativo durante el montaje (Fase 0) y tras un reinicio de cluster completo y la habilitación nuevamente de la asignación (Fase 1, sin tráfico de red adicional):

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt35678fd5b13689c8/60302e8a52b0701387ca3379/blog-cold-tier-testing-1.png" data-sys-asset-uid="blt35678fd5b13689c8" alt="" style="display: block; margin: auto;">

<h2>Situación 2: Reinicio escalonado</h2>
La segunda situación que validamos fue el caso común de <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-rolling">reinicios de cluster escalonados</a>.

El experimento fue similar al del reinicio de cluster completo:

<ol>
	<li>Montamos el snapshot buscable de 5 TB y esperamos a que la memoria caché local estuviera precalentada por completo.</li>
	<li>Ejecutamos el procedimiento de <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-rolling">reinicio escalonado</a> en el primer nodo, para lo cual deshabilitamos la asignación de shards antes de detener cada nodo.</li>
	<li>Iniciamos el nodo tras volver a habilitar la asignación de shards, medimos el tiempo que demoraría para ponerse verde. Esperábamos que fuera rápido debido a la memoria caché persistente. También nos aseguramos de que no hubiera descargas en segundo plano innecesarias después de cada reinicio.</li>
	<li>Repetimos los pasos 2 y 3 para todos los otros nodos del cluster.</li>
</ol>
Este experimento también se completó con éxito y gracias a la memoria caché persistente, que se incorporó en Elasticsearch 7.11, llegar al verde fue prácticamente instantáneo y no hubo descargas adicionales en segundo plano desde el snapshot. 

<h2>Situación 3: Falla de nodo</h2>
Por último, queríamos asegurarnos un comportamiento correcto en el caso de falla de un nodo. Ejecutamos el experimento siguiente:

<ol>
	<li>Montamos el snapshot buscable de 5 TB y esperamos a que la memoria caché local estuviera precalentada por completo (Fase 0).</li>
	<li>De los cinco nodos, terminamos un nodo de Elasticsearch (node-1, con <code>SIGKILL</code>) y esperamos a que el cluster se pusiera verde de nuevo (Fase 1).
	<ol>
		<li style="list-style-type: lower-alpha;">Nos aseguramos de que las descargas en segundo plano están relacionadas con recibir datos de shards hospedados en el nodo terminado.</li>
		<li style="list-style-type: lower-alpha;">Después de ponerse verde, no debería ocurrir ningún balanceo nuevo adicional.</li>
	</ol></li>
	<li>Iniciamos nuevamente el nodo que falló (Fase 2):
	<ol>
		<li style="list-style-type: lower-alpha;">Solo debería realizarse la recuperación de pares (dado que todos los datos existen en los cuatro nodos restantes) para balancear nuevamente los shards.</li>
		<li style="list-style-type: lower-alpha;">El cluster debería ponerse verde.</li>
	</ol></li>
</ol>
Nuevamente, este experimento se completó con éxito. Después de terminar el node-1, los nodos restantes restauraron automáticamente los shards (desde los snapshots buscables) alojados en el nodo faltante.

No hubo ningún balanceo nuevo adicional una vez que el cluster se puso verde, como se puede observar en el gráfico siguiente en el que podemos visualizar el tráfico de red por nodo:

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt01e78a88fe879418/60302ea42568577267da67a3/blog-cold-tier-testing-2.png" data-sys-asset-uid="blt01e78a88fe879418" alt="" style="display: block; margin: auto;">

Tras recuperar el nodo faltante, la recuperación de pares entró en escena y el node-1 terminó alojando nuevamente la cantidad necesaria de shards para tener un cluster de distribución pareja.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt123c74ca4a9ccb9c/60302eb5b6ea0f77f34edd6a/blog-cold-tier-testing-3.png" data-sys-asset-uid="blt123c74ca4a9ccb9c" alt="" style="display: block; margin: auto;">

<h2>Comienza hoy mismo</h2>
Esperamos que este recorrido por la validación de características te haya resultado tan interesante como a nosotros emocionante.

Para dar los primeros pasos con los snapshots buscables y comenzar a almacenar datos en el nivel frío, activa un cluster en <a href="https://info.elastic.co/elasticsearch-service-trial-30d.html">Elastic Cloud</a> o <a href="/es/downloads/">instala la versión más reciente</a> del Elastic Stack. ¿Ya tienes Elasticsearch en ejecución? Solo actualiza los clusters a la versión 7.11 y pruébalo. Si deseas conocer más información, puedes leer la documentación sobre <a href="/guide/en/elasticsearch/reference/7.11/data-tiers.html">niveles de datos</a> y<a href="/guide/en/elasticsearch/reference/7.11/searchable-snapshots-apis.html"> snapshots buscables</a>.

Testing the new Elasticsearch cold tier of searchable snapshots at scale

Prueba del nivel frío nuevo de Elasticsearch de snapshots buscables a escala

Durante la prueba de una característica nueva del Elastic Stack descubrimos un error que afectaba discos SSD en ciertos kernels de Linux. Conoce cómo la investigación involucró una gran colaboración con dos socios cercanos: Google Cloud y Canonical.

En Elastic innovamos y lanzamos características nuevas de forma constante.&nbsp;Mientras lanzamos características nuevas, también trabajamos para asegurarnos de que se hayan probado y sean sólidas y confiables; y a veces encontramos errores u otros problemas.
Durante la prueba de una característica nueva descubrimos un error de kernel de Linux que afectaba los discos SSD en ciertos kernels de Linux. En este blog abarcaremos la historia en torno a la investigación y cómo involucró una gran colaboración con dos socios cercanos: Google&nbsp;Cloud y Canonical.
La investigación resultó en el lanzamiento de nuevos kernels de Ubuntu <a href="#conclusion">para abordar el problema</a>.
 <h2>Cómo comenzó</h2>En febrero de&nbsp;2019, ejecutamos una <a href="/es/blog/benchmarking-elasticsearch-cross-cluster-replication">prueba de estabilidad de 10&nbsp;días</a> para la <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">replicación entre clusters (CCR)</a> con la <a href="https://esrally.readthedocs.io/en/stable/">herramienta de evaluación comparativa de Elasticsearch, Rally</a>, usando una <a href="https://github.com/elastic/rally-eventdata-track/blob/master/eventdata/challenges/bulk-update.json">carga de trabajo de ingesta y con muchas actualizaciones</a>. La versión de Elasticsearch era la publicada más recientemente de la rama&nbsp;7.0 pendiente de lanzamiento (en ese entonces). Tras varios días, la prueba falló y en los logs de Elasticsearch se reportaba lo siguiente:
<pre class="prettyprint">… 
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)
</pre>Al detectar[<a href="#ref1" id="1">1</a>] el daño del índice, Elasticsearch intentará recuperarse a partir de una réplica. En muchos casos la recuperación no presenta problemas y, a menos que el usuario revise los logs, el daño pasará desapercibido. Incluso con la redundancia que ofrecen las réplicas, es posible que se produzca la pérdida de datos en ciertas circunstancias. Por lo tanto, queríamos comprender por qué se producía el daño y explorar cómo podíamos remediar el problema.
Al principio, sospechábamos que una característica nueva de Elasticsearch, <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">CCR</a>/<a href="https://github.com/elastic/elasticsearch/issues/29530">eliminaciones parciales</a>, causaba el problema. Descartamos rápidamente esta sospecha, sin embargo, cuando descubrimos que podíamos reproducir el daño en el índice usando un solo cluster y deshabilitando la característica de CCR/eliminaciones parciales. Después de más investigación, descubrimos que podíamos reproducir el problema en versiones anteriores de Elasticsearch previas al lanzamiento beta de CCR/eliminaciones parciales, lo que sugería que las CCR/eliminaciones parciales no eran la causa del daño en el índice.
Sin embargo, sí notamos que las pruebas e investigación que llevaron al daño en el índice se habían realizado en Google&nbsp;Cloud&nbsp;Platform&nbsp;(GCP) usando la <a href="https://console.cloud.google.com/marketplace/details/ubuntu-os-cloud/ubuntu-xenial">imagen Ubuntu Xenial de Canonical</a> y <a href="https://cloud.google.com/compute/docs/disks/local-ssd">SSD locales</a> con el kernel <code>4.15-0-*-gcp</code> y que no podíamos reproducir el problema en un entorno de metal expuesto con el mismo sistema operativo y discos SSD (ya sea con <a href="https://wiki.ubuntu.com/Kernel/LTSEnablementStack">kernels HWE</a> 4.13 o 4.15).
Nuestra atención se centró inmediatamente en Elastic&nbsp;Cloud para obtener más datos sobre el problema y su impacto. En un flujo de trabajo paralelo, descartamos varias sospechas probando diferentes sistemas de archivos, deshabilitando RAID y usando por último un kernel principal más nuevo. Pero nada de esto hizo desaparecer los daños.
 <h2>Profundizando con el soporte de Google&nbsp;Cloud</h2>En este punto, creamos un conjunto de <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">scripts de fácil reproducción</a> para facilitar las reproducciones e involucramos a nuestro socio Google para comenzar a investigar en mayor profundidad los problemas del entorno.
El soporte de GCP logró reproducir el problema de forma confiable usando los scripts proporcionados, con un mensaje de error de ejemplo:
<pre class="prettyprint">org.apache.lucene.index.CorruptIndexException: codec footer mismatch (file 
truncated?): actual footer=-2016340526 vs expected footer=-1071082520 
(resource=BufferedChecksumIndexInput(MMapIndexInput(path="/home/dl/es/data/nodes/0/indices/IF1vmFH6RY-MZuNfx2IO4w/0/index/_iya_1e_Lucene80_0.dvd")))
</pre>Durante el período en el que ocurrió el problema, el rendimiento de E/S superó los 160&nbsp;MB/s con 16&nbsp;000&nbsp;IOPS. Esta observación fue coherente en varias pruebas. Como Elasticsearch (de forma predeterminada) usa <a href="/guide/en/elasticsearch/reference/7.8/index-modules-store.html#file-system">archivos mapeados en memoria en parte de su almacenamiento</a>, sospechábamos que algunos accesos a los archivos causaban fallas de la página más importantes, lo que aumentaba las operaciones de E/S en el disco y desencadenaba el problema en última instancia. Para reducir la ocurrencia de una falla de la página, intentamos aumentar la memoria de las instancias de GCP de 32&nbsp;GB a 52&nbsp;GB. Con el aumento de la memoria, el problema ya no ocurría y el rendimiento de E/S era de 50&nbsp;MB/s con 4000&nbsp;IOPS.&nbsp;
El primer descubrimiento sucedió cuando observamos una diferencia entre GCP y el entorno de metal expuesto: el kernel de GCP tenía una característica denominada <a href="https://lwn.net/Articles/738449/">capa de bloqueo multicolas</a> (blk_mq) habilitada, que el kernel de metal expuesto no[<a href="#ref2" id="2">2</a>]. Para complicar aún más las cosas, después de una versión determinada[<a href="#ref3" id="3">3</a>] ya no es posible deshabilitar blk_mq[<a href="#ref4" id="4">4</a>] en la imagen de Ubuntu Linux -gcp a través de las opciones de kernel. El soporte de GCP nos mostró cómo deshabilitar blk_mq exportando la imagen de Ubuntu de GCP y recreándola sin la característica VIRTIO_SCSI_MULTIQUEUE para SO invitado, que habilita SCSI multicola[<a href="#ref5" id="5">5</a>].
El segundo descubrimiento fue lograr reproducir el daño en metal expuesto: fue posible únicamente habilitando explícitamente <code>blk_mq</code> incluso usando un kernel más antiguo: <code>4.13.0-38-generic</code>. También verificamos que los discos NVMe no muestran este problema.
En este punto sabíamos que los daños ocurren cuando se cumplen las dos condiciones siguientes:
<ul>
	<li>Unidades SSD con interfaz SCSI (los discos NVMe no se ven afectados)</li>
	<li>blk_mq habilitado</li>
</ul>El soporte de GCP compartió dos soluciones alternativas adicionales (además de usar solo discos NVMe): aumentar la memoria de la instancia o crear imágenes de la instancia personalizadas con la opción SCSI multicola deshabilitada.
 <h2>Canonical se une al esfuerzo</h2>Si bien teníamos algunas soluciones alternativas, aún no estábamos satisfechos:
<ul>
	<li>El problema no era específico de las imágenes de Ubuntu en GCP, también sucedía en metal expuesto.</li>
	<li>No sabíamos cuál publicación de kernel introdujo el problema.</li>
	<li>No sabíamos si ya había una solución disponible en un kernel más nuevo.</li>
</ul>Para abordar estos puntos, recurrimos a nuestro socio Canonical para que profundizara un poco más.
Canonical inició un gran esfuerzo de pruebas usando <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">scripts de reproducción de Elastic</a>, primero confirmó que el daño no ocurría en kernels principales de Ubuntu &gt;=5.0 con unidades SSD (sin usar <a href="https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers">programadores de E/S multicola</a> o usando los mq-deadline).
El paso siguiente fue retroceder en las versiones de kernel para encontrar el delta mínimo entre un kernel que mostraba daño y uno que no. En entornos de pruebas en paralelo múltiples (dado que una ejecución de prueba completa puede tomar hasta cinco días), Canonical descubrió que el kernel principal de Ubuntu <a href="https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.8/">4.19.8</a> es el primero que incluye soluciones para el daño[<a href="#ref6" id="6">6</a>].
Los backports faltantes del kernel 4.15.0 y derivados se describen en el rastreador de errores de Canonical, en <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">LP#1848739</a>, y se incluyen más detalles en <a href="https://lwn.net/Articles/774440/">este artículo</a> y en el <a href="https://bugzilla.kernel.org/show_bug.cgi?id=201685">error de kernel.org</a>.
Después de que Elastic y Canonical confirmaran que un kernel de GCP con parche y todos los backports necesarios <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/9">soluciona el problema</a>, se <a href="https://lists.ubuntu.com/archives/kernel-team/2019-December/106382.html">combinaron</a> en el kernel principal de Ubuntu 4.15.0 y todos los kernels derivados (incluido -gcp) recibieron las soluciones.
 <h2 id="conclusion">Conclusión</h2>Elastic está comprometido con desarrollar características del Elastic Stack nuevas que mejoren cada una de nuestras tres soluciones primarias. Estos esfuerzos cuentan con el soporte de algunos socios e ingenieros muy talentosos que siempre están atentos para que no debas preocuparte. Cuando encontramos problemas (si lo hacemos) durante las pruebas, debes saber que Elastic y su red de socios cercanos no descansarán hasta asegurarse de que tengas la mejor experiencia posible.
Gracias a nuestra estrecha colaboración con Google y Canonical, pudimos llegar a la raíz del problema, lo que llevó al lanzamiento de los siguientes kernels de HWE Ubuntu <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">solucionados</a>:
<ul>
	<li>AWS: a partir de <code>linux-aws - 4.15.0-1061.65</code> lanzado el <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-aws/linux-aws_4.15.0-1061.65/changelog">21 de febrero de 2020</a></li>
	<li>Azure: a partir de <code>linux-azure - 4.15.0-1066.71</code> lanzado el <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/12">6 de enero de 2020</a></li>
	<li>GCP: a partir de <code>linux-gcp - 4.15.0-1053.57</code> lanzado el <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-gcp/linux-gcp_4.15.0-1053.57/changelog">5 de febrero de 2020</a></li>
	<li>Genérico: a partir de <code>linux - 4.15.0-88.88</code> lanzado el <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/15">17 de febrero de 2020</a></li>
</ul>El uso de las versiones mencionadas anteriormente o más nuevas evitará daños cuando se usen discos SSD junto con la opción SCSI blk-mq habilitada.
Si no quieres preocuparte por si tu entorno está protegido de los daños a los datos, prueba nuestro <a href="/es/elasticsearch/service">Elastic Cloud</a>; nuestros usuarios ya están protegidos.
 <h2>Notas al pie</h2>[<a href="#1" id="ref1">1</a>] Elasticsearch no verifica las sumas de comprobación todo el tiempo debido a que es una operación costosa. Ciertas acciones pueden desencadenar la verificación de sumas de comprobación con más frecuencia, como la reubicación de shards o mientras se realiza un snapshot, lo que hará que los daños silenciosos subyacentes aparezcan si fueron causados por estas acciones.
[<a href="#2" id="ref2">2</a>] Para comprobar si se usa blk_mq para SCSI o discos de mapeo de dispositivos, usa <code>cat /sys/module/{scsi_mod,dm_mod}/parameters/use_blk_mq</code>.
[<a href="#3" id="ref3">3</a>] Después de que se haya forzado <a href="https://patchwork.kernel.org/patch/10198305">https://patchwork.kernel.org/patch/10198305</a> blk_mq en dispositivos SCSI y no se pueda deshabilitar a través de las opciones del kernel. Este parche se aplicó en backport en Ubuntu <a href="https://launchpad.net/ubuntu/+source/linux-gcp/4.15.0-1010.10~16.04.1">linux-gcp</a>.
[<a href="#4" id="ref4">4</a>] Para deshabilitar blk_mq, se deben pasar los parámetros siguientes al kernel, por ejemplo, a través de grub: <code>GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=N dm_mod.use_blk_mq=N"</code>. La habilitación se puede hacer configurando estas opciones como N, pero ten cuidado con [3].
[<a href="#5" id="ref5">5</a>] Comandos de ejemplo de gcloud para deshabilitar la característica VIRTIO_SCSI_MULTIQUEUE para SO invitado recreando la imagen de Ubuntu:
<pre># gcloud compute images export --image-project ubuntu-os-cloud --image-family ubuntu-1604-lts --destination-uri=gs://YOUR_BUCKET/ubuntu_16.04.tar.gz 
# gcloud compute images create ubuntu-1604-test --family ubuntu-1604-lts --source-uri=gs://YOUR_BUCKET/ubuntu_16.04.tar.gz
</pre>[<a href="#6" id="ref6">6</a>] Backports
<pre> - blk-mq: quiesce queue during switching io sched and updating nr_requests 
 - blk-mq: move hctx lock/unlock into a helper 
 - blk-mq: factor out a few helpers from __blk_mq_try_issue_directly 
 - blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback 
 - dm mpath: fix missing call of path selector type-&gt;end_io 
 - blk-mq-sched: remove unused 'can_block' arg from blk_mq_sched_insert_request 
 - blk-mq: don't dispatch request in blk_mq_request_direct_issue if queue is busy 
 - blk-mq: introduce BLK_STS_DEV_RESOURCE 
 - blk-mq: Rename blk_mq_request_direct_issue() into 
 blk_mq_request_issue_directly() 
 - blk-mq: don't queue more if we get a busy return 
 - blk-mq: dequeue request one by one from sw queue if hctx is busy 
 - blk-mq: issue directly if hw queue isn't busy in case of 'none' 
 - blk-mq: fix corruption with direct issue 
 - blk-mq: fail the request in case issue failure 
 - blk-mq: punt failed direct issue to dispatch list
</pre>

blog-banner-cloud-gcp-region.png

blog-thumb-cloud-gcp-region.png

Canonical, Elastic, and Google team up to prevent data corruption in Linux

Canonical, Elastic y Google se unen para evitar el daño de datos en Linux

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

headshot-dimitrios-liappis-300x300.jpg

Software Engineer

Dimitrios Liappis

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

El contenido de esta página no está disponible en el idioma seleccionado. Elastic está trabajando para garantizar que el contenido esté disponible en varios idiomas. Gracias por tu paciencia mientras trabajamos.

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

Al enviar, confirma que ha leído y acepta nuestras <a href="/es/legal/elastic-cloud-account-terms" target="_self">Condiciones de servicio</a>, y que acepta recibir las <a href="/es/legal/privacy-statement#how-we-use-the-information" target="_self">comunicaciones seleccionadas</a> en los detalles de contacto que proporcionó anteriormente. Consulte la <a href="/es/legal/privacy-statement/" target="_self">Declaración de privacidad de Elastic</a> para obtener más información o para cancelar su suscripción en cualquier momento.

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

Al enviar, confirma que ha leído y acepta nuestras <a href="/es/legal/serverless-preview-terms" target="_self">Condiciones de servicio</a>, y que Elastic puede <a href="/es/legal/privacy-statement#how-we-use-the-information" target="_self">ponerse en contacto con usted</a> acerca de nuestros productos y servicios relacionados. Consulte la <a href="/es/legal/privacy-statement/" target="_self">Declaración de privacidad de Elastic</a> para obtener más información o para cancelar su suscripción en cualquier momento.

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

Al enviar esta información, aceptas los <a href="/es/agreements/global/cloud-services-monthly" rel="nofollow">Términos de servicio de Elastic</a>. Los datos personales se procesarán de conformidad con la <a href="/es/legal/privacy-statement">declaración de privacidad de Elastic</a>.

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

Al enviar, confirma que ha leído y acepta nuestras <a href="/es/legal/terms-of-use" target="_self">Condiciones de servicio</a>, y que Elastic puede <a href="/es/legal/privacy-statement#how-we-use-the-information" target="_self">ponerse en contacto con usted</a> acerca de nuestros productos y servicios relacionados. Consulte la <a href="/es/legal/privacy-statement/" target="_self">Declaración de privacidad de Elastic</a> para obtener más información o para cancelar su suscripción en cualquier momento.

Hosted by

All Solutions

Follow us on Youtube

Watch now (no PT)

Articles by

Share by Email

Filters

All (no PT translation)

Contact information

See when this webinar starts in my time zone

Ver cuándo comienza este webinar en mi zona horaria

Thank you for your interest!

Register to Attend

Small image for

Register to Watch

Continue reading

Featured webinar

What to explore next...

Reset all

Load more press releases

Sign In to Attend

Share

Upcoming webinar

Learn more

Search Integrations

Share on Reddit

Share on Twitter

Share on Facebook

Load more news

View more posts

On-demand webinar

Follow us on Facebook

Author

Press Release

You'll also receive an email with related content.

You'll also receive an email with related content

Además, te enviaremos contenidos relevantes

Print

Contact Info

Overview

Video for

Read less

Register now

Share this story

See All Posts

See all top stories

View next

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

¿No puedes asistir? Regístrate y te enviaremos la grabación. También recibirás un correo electrónico con contenido relacionado.

Follow us on LinkedIn

Highlights

Explore similar demos

Follow us on Twitter

Share on LinkedIn

Load More

See more insights

Speakers

Close

Thank you for registering. We will send you a confirmation email soon.

Gracias por registrarte. Te enviaremos un correo electrónico de confirmación pronto.

Author

Articles by Dimitrios Liappis

Software Engineer, Elastic

Benchmark-driven optimizations — How we pushed scalability to the next level in Elasticsearch 8

Prueba del nivel frío nuevo de Elasticsearch de snapshots buscables a escala

Canonical, Elastic y Google se unen para evitar el daño de datos en Linux