Explorando Transferência De Arquivos Para Dispositivos Externos

Isso é verdade para shells que em time é programa externo ou um comando interno.

Na verdade, seu código em subshell nem funciona em shells que têm o time que tem essa restrição, como o dash, já que o ( também é um grupo de comandos (só que rodados numa fork() do shell atual).

$ dash -c 'time ( echo Estou no subshell. )'
dash: 1: Syntax error: word unexpected (expecting ")")

O bash (assim como os *ksh) implementa o time como uma palavra-chave, o que significa que, qualquer coisa que você possa digitar no shell, pode ser medida (incluindo pipelines com múltiplos comandos, grupos de comandos, etc.

Enfim, a discussão aqui é meio bizantina, o tempo gasto no fork()exec() é desprezível em comparação com os comandos que rodam dentro do subshell – mas em outros casos, pode distorcer os resultados em favor do comando simples sem ().

2 curtidas

interessante. :slight_smile:

Poisé…

Sempre achei mais relevante a distinção entre {} e () quando busco preservar contexto por exemplo dentre outros efeitos colaterais de cada.

Saindo um pouco do tópico, seria interessante saber como faz se nem:

time { echo 1; echo 2; }

Funciona no dash. :confused:

Usando um exemplo um pouco mais realista de como isso de ( e sem podem afetar:

$ time tr '[:lower:]' '[:upper:]' < 2000linhas.txt > /dev/null

real    0m0,001s (máximo)
user    0m0,000s
sys     0m0,001s
$ time (tr '[:lower:]' '[:upper:]' < 2000linhas.txt > /dev/null)

real    0m0,003s (mínimo)
user    0m0,002s
sys     0m0,001s

Isso pode não fazer a diferença num comando trivial, ou num único comando gigante, mas numa sequência de comandos pequenos, a distorção pode se acumular.

No dash, você realmente tem que fazer um único comando (trazendo penalidades parecidas ao ( do bash):

time dash -c 'echo 1; echo 2;'

Para tornar a comparação honesta, é interessante fazer o mesmo com o comando simples.

time dash -c 'echo 1'
1 curtida

Ainda assim parece afetar pouco, não sei se isso é mais um problema de amostragem que do custo associado a cada modo:

Mas eu concordo, realmente você encontra este tipo de amplificação no shell dependendo de como o comando é construído e recurções e loops são tratados só não diria que são simples considerando o nível de abstração escondendo o trabalho. De qualquer forma bem interessante!

1 curtida

E ele esbarrou já de cara no clássico “100% transferido só que não” por estar transferindo um arquivo grande o bastante para resultar nesse bug… Isso já foi discutido aqui, mas aparentemente para muita gente esse problema não existe de verdade…

7 curtidas

Pra mim n existe. Aposto até dinheiro com quem duvidar. Tô precisando comprar um cartão de memória novo.
Ps. Recebo preferencialmente via pix

É um problema que afeta todos até onde eu sei, pelo menos que usa o gerenciador de arquivos…
fica neste estado:

2 curtidas

Ninguém vai apostar isso com você, da mesma forma que ninguém vai ver a maioria desses defeitos que muitas vezes fanboys de interface ou distro X e Y não enxergam. Porque ninguém quer ver nada que não o afeta pessoalmente, mesmo que um famoso de TI passe por isso ao vivo.

3 curtidas

shhhh faz de conta que não viu…

Se não me engano este bug está relacionado com ele ainda passar o resto do arquivo armazenado em buffer para o destino, mesmo o processo em 100% (o mesmo ocorre com o dd)

1 curtida

é eu sei, é antigo…

@henriquead7 compartilha disso

3 curtidas

é inevitável passar pelo buffer do kernel, é necessário, não é seguro escrever diretamente no dispositivo, o problema é você passar tudo rapidamente para o buffer do kernel, o sistema só monitora a transferência para o buffer, não do buffer para o dispositivo. Eu cheguei a fazer uma demonstração em C de como corrigir esse problema, consiste em alimentar o buffer de forma controlada, em alguns casos melhora a performance porque idealmente nenhum processo deveria sobrecarregar o buffer que é compartilhado entre todos os dispositivos, esta sobrecarga resulta em overhead da gestão da queue do buffer.

1 curtida

Claro q n vai apostar. Ninguém gosta de perfer dinheiro. Então deixo a lição pra vc: Não trate problemas isolados no seu computador como característica geral.
Pessoal usa distro feita pelo zezinho youtuber 123, ou fica mexendo em configurações q n sabe pra dps culpar o Linux por problemas q (na maioria das vezes) o próprio usuário causou.

Não é isso, é que ninguém quer apostar quando está na mesa a regra “se quer apostar comigo tem que saber que eu sempre vou vencer porque essa é a regra”. Da mesma forma que ninguém vai ver problema algum se não quiser ver. Não tenho nada contra quem quer por as coisas dessa forma de qualquer forma, eu sei que disse o óbvio.

1 curtida

Tá. Pois n precisamos apostar. Vamos só esclarecer q esse n é uma característica do Linux pode ser? Afinal, se fosse era para o problema ocorrer comigo tmb. Vc concorda?

Eu sei, mesmo que o Linus mostre esse show stopper ao vivaço. Desde que não aconteça na minha casa não existe.

O que acontece é isso: minhas transferências ocorrem normalmente e da mesma forma no meu Ubuntu, Windows 10 e Mac. Se vc quiser verificar por si só estarei a disposição para gravar um vídeo demonstrando q n tenho esse tipo de problema. Até onde sei eu n sou especial pra só eu no mundo Linux n ter esse tipo de problema certo?

Eu não quero verificar que você nega que esse problema existe, você sabe disso.

Kkk. N pow. Eu n tô negando q esse problema exista. Tô dizendo é q ao meu ver é caso isolado, justamente porq eu n tenho. Eu sei q problema é esse. Acompanhei um post aki no fórum sobre isso. O que eu quero entender é porq estão tratando como característica sendo q nos meus computadores com Ubuntu não ocorre. E não sei porq vc se esquiva tanto de fazermos os testes. Isso n iria provar um de nossos pontos? Vou dar um exemplo: vc grava um vídeo mostrando o problema. E aí eu gravo o meu fazendo exatamente e com o mesmo arquivo todos os passos q vc fez. Eai vamos ver se isso é realmente um bug geral. Q tal?