Estou planejando usar o btrfs em um array RAID6 de 50 TB e quero ativar a compactação lzo.
Isso é para a configuração de bioinformática, onde muita procura em arquivos grandes (1 TB - 20 TB) ocorre. (O software obtém apenas pequenos pedaços de dados espalhados pelo arquivo).
O que me preocupa é que não entendo como a busca é realizada em sistemas de arquivos compactados como o btrfs. O arquivo precisa ser descompactado desde o começo até a posição procurada primeiro? Isso teria um impacto negativo enorme na minha configuração.
Ou uma pergunta mais geral: a escala de tempo de busca com o tamanho do arquivo é igual à do sistema de arquivos não compactado ou piora, por exemplo? O (tamanho_de_ficheiro)
Os tempos de pesquisa aleatória também serão aproximadamente O (1) como sistemas de arquivos descompactados, mas com a limitação de que até 128 KiB de dados são compactados juntos para ler apenas um único byte, todos os dados nesse bloco de 128 KiB terá que ser lido e descompactado. Dependendo do padrão de acesso, isso pode ter um impacto de desempenho um pouco grande, mas é necessário fazer um benchmark disso com seu aplicativo e conjunto de dados específicos.
( Fonte )
Há muita desinformação sobre a compactação FS na Internet e aqui no Stackoverflow. A compactação do sistema de arquivos é feita no nível do bloco (ou nível do fragmento, dependendo do dispositivo), não no nível de abstração do arquivo, portanto a busca ostensiva é a mesma - a busca de arquivos é feita em termos de blocos, não em termos de bits compactados. O que isso significa é que a compactação em si não é exposta aos programas no nível do usuário. Então você não precisa pensar sobre isso ou se preocupar com isso.
Uma maneira "super excessivamente simples" de visualizar: x / 0 são blocos, grupos de blocos em um arquivo. arquivos não compactados & blocos: [xxx] [xxx] [xxx] [xxx] arquivos compactados & blocos: [xx] 0 [xx] 0 [xx] 0 [xx] 000 Na verdade, não é bem assim, mas o arquivo inodes apontará para blocos compactados e deixará de fora o espaço que o arquivo não precisa.
Em princípio, não há motivo atual para ativar a compactação fs. Além de alguns casos periféricos, o desempenho da compactação fs é estritamente melhor do que as leituras não compactadas. Para dados de bioinformática, com os quais trabalhei também, você às vezes deseja maximizar sua largura de banda de leitura, e a compactação atingirá isso - ou seja, as velocidades de leitura de dados não compactadas excederão os limites do controlador + da interface. (N bits compactados em sata III / raid se tornam bits de taxa de compressão N *). Não preste atenção em qualquer bobagem que as pessoas dizem sobre a latência, reduzindo a velocidade do processador, etc. A CPU é 1000 vezes mais rápida que a leitura do disco.
Para alguns benchmarks de desempenho, aqui: link
Outra confusão pode surgir se misturarmos a compactação no nível de arquivo (ou seja, gzip ou xz, etc) com a compactação no nível do sistema de arquivos. Nesses casos, sim, a busca de arquivo é não-determinística e os locais de dados absolutos no arquivo não estão estritamente disponíveis sem descompactar o fluxo de bytes anterior apenas para localizar os deslocamentos de definição do dicionário dentro do arquivo. Portanto, com a compactação no nível do fs, você continua procurando a perda de alguma compressibilidade.
Como um aparte, o motivo pelo qual a compactação de nível de bloco / fs é geralmente (e historicamente) desabilitada é porque pode aumentar a fragmentação dentro de um arquivo, especialmente com gravações de arquivo intermediárias. Para unidades antigas, ou unidades com arquivos de banco de dados, a própria fragmentação pode incorrer em uma penalidade de desempenho (isso ainda é verdade com ssd, mas devido ao ciclo de reescrita / exclusão de blocos, não por causa da cabeça de leitura em movimento linear). Se este for um gigantesco fluxo bioinformático, então as midwrites podem não ser um problema.
Em geral, busque escalas de tempo como uma função do layout do inode e do sistema de arquivos. Não é tamanho de arquivo. Por exemplo. se você tiver dois arquivos, tamanho grande X e tamanho Y maior, nenhum dos quais caberá no readahead e no cache do disco, nem pode ser lido em uma única leitura de inode, então o tempo para atingir a posição x em X é aproximadamente igual ao tempo para alcançar a posição y em Y, onde x < y. Há casos em que pode parecer diferente, mas esses são para outros fatores não controlados, como a posição rotacional no prato giratório. Ou os arquivos X e Y estão sendo abertos e lidos como fluxos. Então todo X até pos x tem que ser lido, e o mesmo para Y. Mas isso não é uma função do sistema de arquivos. Um comando fseek () diretamente em diferentes posições do arquivo irá revelar tempos de busca similares. (Novamente a posição depende do prato).
HTH.
Tags performance compression btrfs