Zstd: Diferenças entre gzip e zstd

Criado em 19 set. 2017 · 4Comentários · Fonte: facebook/zstd

zstd no Linux: duas observações

1) Se eu iniciar o gzip para compactar um arquivo grande e se eu matar o gzip usando ^ C, o gzip excluirá o arquivo de saída antes de encerrar. O zstd atualmente não faz isso. Acho que o comportamento do gzip é melhor, porque é melhor não ter nenhum arquivo de saída do que ter um arquivo de saída incompleto ou corrompido.

2) Ao compactar ou descompactar um arquivo, zstd usa a chamada de sistema abaixo para criar o arquivo de saída (do strace):
open("file.zst", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
gzip e xz usam chamadas de sistema semelhantes, mas usam o modo 0600. Eles mudam o modo do arquivo de saída para o modo desejado após o arquivo ser fechado. Existe uma razão pela qual zstd usa 0666? Acho que 0600 seria melhor: não permita o acesso de leitura a outros usuários antes que o arquivo esteja pronto.

feature request question

Fonte

ghost

Todos 4 comentários

capturar o evento ^C requer um manipulador de sinal. Eu não olhei para isso ainda. Também estou preocupado com questões de portabilidade.
Seu rastreamento é mais preciso do que nosso código.
A chamada para abrir o arquivo de destino está aqui:
https://github.com/facebook/zstd/blob/dev/programs/fileio.c#L324
É apenas um fopen("name", "wb"); padrão, não controlamos nenhum bit de propriedade.
Acontece que se traduz neste rastreamento em seu sistema, apenas saiba que não temos controle sobre ele.
Em geral, tentamos permanecer o mais próximo possível do padrão C, por motivos de portabilidade (e redução da dor de cabeça de dependência).

Cyan4973 em 19 set. 2017

Em primeiro lugar: obrigado por escrever zstd. Estou impressionado com a velocidade e a taxa de compressão! Muito agradável!

Sinta-se à vontade para fechar este tíquete. Minhas duas observações são apenas pequenos detalhes e está perfeitamente bem se você decidir não fazer nada.

Eu concordo que o trapping ^ C requer um manipulador de sinal.
Interessante. Eu olhei para o código-fonte de xz e eles abriram o arquivo de saída com o código abaixo:

      int flags = O_WRONLY | O_BINARY | O_NOCTTY | O_CREAT | O_EXCL;
      #ifndef TUKLIB_DOSLIKE
          flags |= O_NONBLOCK;
      #endif
      const mode_t mode = S_IRUSR | S_IWUSR;
      dest_fd = open( dest_name, flags, mode );

Eles usam open () em vez de fopen () - e assim podem controlar os bits de permissão do arquivo de saída.

ghost em 19 set. 2017

👍1

Certo, acredito que xz visa sistemas em conformidade com POSIX ,
portanto, ele pode usar bibliotecas posix livremente, ao custo de não ser compatível com sistemas não-posix ou exigir invólucros personalizados (o Windows vem à mente).

zstd tenta ser padrão-C tanto quanto possível, para melhorar as perspectivas de portabilidade.

Tecnicamente, também usamos ocasionalmente algumas interfaces dependentes do sistema operacional, quando não há equivalente padrão-C. Nesse caso, tentamos escrever várias variantes para oferecer suporte a vários destinos e, para aqueles sem suporte, as funcionalidades relevantes são desativadas de forma limpa (eles tendem a ser não essenciais).

Cyan4973 em 19 set. 2017

Depois de aprender um pouco mais sobre isso, parece que a função signal() é na verdade parte do C padrão , o que a torna bastante portátil.

Na última atualização de dev branch, adicionei Ctrl-C trapping a zstd cli.
Ao pressionar Ctrl-C , ele agora apaga o artefato de operação (arquivo de destino não concluído) antes de sair.

Cyan4973 em 1 out. 2017

❤1

Esta página foi útil?

0 / 5 - 0 avaliações