A “aceleração de write-back” é uma solução para o “problema de bloqueio de pendrive”?

Question

The pernicious USB-stick stall problem - LWN.net, 2013.

Plug a slow storage device (a USB stick, say, or a media player) into a Linux machine and write a lot of data to it. The entire system proceeds to just hang, possibly for minutes.

O artigo previu uma mudança simples nos padrões do kernel. Em x86 de 64 bits, o cache de write-back foi permitido aumentar para 20% da RAM do sistema por padrão. Linus sugeriu limitar efetivamente a ~ 180MB em todas as plataformas, imitando uma limitação do código x86 de 32 bits. No entanto, o Linux atual (v4.18) não inclui a alteração sugerida. (Compare o patch de Linus , para o sempresa atual na v4.18 ).

O artigo do LWN de 2013 diz que o problema é "um armazenamento equivalente ao problema do bufferbloat". Agora, há um artigo sobre o LWN de 2016 em um novo recurso do Linux, chamado otimização de write-back ( wbt / CONFIG_WBT / wbt_lat_usec ). O artigo descreve a aceleração de write-back como uma maneira de atenuar "um problema de bufferbloat que espelha os problemas que foram vistos na pilha de rede". Isso está soando muito parecido: -).

O problema específico de pendrive USB agora foi resolvido?

Toward less-annoying background writeback - LWN.net, 2016

It's an experience many of us have had: write a bunch of data to a relatively slow block device, then try to get some other work done. In many cases, the system will slow to a crawl or even appear to freeze for a while; things do not recover until the bulk of the data has been written to the device. On a system with a lot of memory and a slow I/O device, getting things back to a workable state can take a long time, sometimes measured in minutes. Linux users are understandably unimpressed by this behavior pattern, but it has been stubbornly present for a long time. Now, perhaps, a new patch set will improve the situation.

Inspirado por esta pergunta: O sistema fica lento ao executar grandes operações de R / W nos discos externos

    

Answer 1

O artigo "USB-stick stall" não fornece evidências para sua reivindicação. Eu acho que é muito enganador e talvez errado:

Por que foram relatados problemas "USB-stick stall" em 2013? Por que esse problema não foi resolvido pelo código existente de "limitação I / O suja"?

Eu acho que o travamento do sistema descrito é evitado, ou pelo menos mitigado, pelo código "No-I / O dirty throttling". Esse código também foi descrito no LWN, em 2011. Ele controla as chamadas write () para controlar o tamanho do cache geral de write-back e a quantidade de cache de write-back para o dispositivo de backup específico .

O problema relatado ao linux-kernel em 2013 fez não ver todo o sistema travar, enquanto estava liberando as gravações em cache para um pendrive. Isso pode ter sido um problema em kernels mais antigos, e talvez haja um problema diferente de stall / hang, que parece similar o suficiente para ser confundido com este.

O relatório inicial simplesmente reclamou que o Linux permitia uma grande quantidade de gravações em cache em um dispositivo lento, o que poderia levar até "dezenas de minutos" antes de terminar. Um acompanhamento relatou que a gravação de 10 GB em um disco interno do servidor fazia com que o sistema travasse ou pelo menos sofresse atrasos extremamente longos na resposta.

Resposta anterior (isto é, incorreta):

Em primeiro lugar, o WBT não funciona com os escalonadores CFQ ou IQ do BFQ. O Debian e o Fedora usam o CFQ por padrão, então o WBT não ajudará em pen drives (nem em discos rígidos) a menos que você tenha alguma configuração especial.

Tradicionalmente, o CFQ tem sido usado para trabalhar bem com discos rígidos giratórios. Eu não estou totalmente certo de onde isso deixa o WBT. Talvez a principal vantagem do WBT seja para SSDs, que são mais rápidos do que girar discos rígidos, mas muito lentos para tratar como RAM?

Ou talvez seja um argumento usar o deadline scheduler, e abrir mão dos recursos do CFQ. O Ubuntu mudou para deadline na versão 14.04 , mas voltou para CFQ porque version 17.04 (zesty) . (Acho que o CentOS 7.0 é muito antigo para ter o WBT, mas ele alega usar CFQ para unidades SATA e deadline para todas as outras unidades. O CentOS 7.0 também suporta unidades NVMe, mas mostra apenas "none "para o agendador.)

Mas, se você for capaz de usar o WBT, ele ajudará o "problema de paralisação do pendrive"? Eu não penso assim.

O código WBT que foi mesclado limita o número de solicitações IO enviadas para cada dispositivo individual. O código WBT que foi adicionado não define diretamente os limites do cache de write-back, ou seja, o cache de páginas

sujo

.

O tópico da lista de discussão de 2013 sobre o problema do pendrive, mencionou limites por dispositivo para a sujeira cache de páginas como uma possibilidade de trabalho futuro .

Acho que a ativação do WBT não protege você de encher o cache de páginas sujas com gravações em um único dispositivo e causar paralisações nas gravações em todos os dispositivos.

O cenário descrito para o WBT é quando você está escrevendo um grande lote de dados para o seu disco main , e ao mesmo tempo você quer continuar usando o seu disco principal interativamente, para carregar programas etc.

O problema do pendrive USB é sobre como gravar um grande lote de dados em um disco diferente / USB externo, etc. e, ao mesmo tempo, você quer ser capaz de gravar interativamente no disco principal.