RHEL5: Não é possível criar arquivos esparsos maiores que 256 GB em tmpfs

Question

/var/log/lastlog é gravado quando você faz login. O tamanho desse arquivo é baseado no maior UID do sistema. Quanto maior o UID máximo, maior será esse arquivo. Felizmente, é um arquivo esparso, portanto, o tamanho no disco é muito menor que o tamanho ls reports ( ls -s informa o tamanho no disco).

Em nosso sistema, estamos autenticando em um servidor do Active Directory, e os usuários de UIDs são atribuídos, sendo realmente muito grandes. Como, digamos, UID 900.000.000 para o primeiro usuário do AD, 900.000,001 para o segundo, etc.

Isso é estranho, mas deve ficar bem. Isso resulta em /var/log/lastlog sendo huuuuuge, embora - quando um usuário do AD efetua login lastlog aparece como 280 GB. Seu tamanho real ainda é pequeno, felizmente.

Isso funciona bem quando /var/log/lastlog é armazenado no disco rígido em um sistema de arquivos ext3. Ele quebra, no entanto, se lastlog estiver armazenado em um sistema de arquivos tmpfs. Em seguida, parece que o tamanho máximo do arquivo para qualquer arquivo no tmpfs é de 256 GB, portanto, o programa sessreg comete erros ao tentar gravar em lastlog .

De onde vem esse limite de 256 GB e como posso aumentá-lo?

Como um teste simples para criar grandes arquivos esparsos que tenho feito:

dd if=/dev/zero of=sparse-file bs=1 count=1 seek=300GB

Eu tentei pesquisando por "tmpfs tamanho máximo do arquivo", "limite de 256GB filesystem", "tamanho máximo do arquivo linux", coisas assim. Eu não fui capaz de encontrar muito. A única menção de 256GB que eu posso encontrar é que os sistemas de arquivos ext3 com blocos de 2KB são limitados a arquivos de 256GB. Mas nossos discos rígidos são formatados com blocos de 4K, o que não parece ser - para não mencionar isso está acontecendo em um tmpfs montado em cima do disco rígido para a partição ext3 não deve ser um fator.

Isso tudo está acontecendo em um sistema Red Hat Enterprise Linux 5.4 de 64 bits. Curiosamente, na minha máquina de desenvolvimento pessoal, que é uma caixa Fedora Core 6 de 32 bits, eu posso criar 300GB + arquivos em sistemas de arquivos tmpfs não há problema. Nos sistemas RHEL5.4, não é necessário.

    

Answer 1

A resposta é encontrada no código fonte do Linux, especificamente, /usr/src/linux/mm/shmem.c , começando em torno da linha 70 em meu sistema (Gentoo 2.6.31-ish):

/*
 * The maximum size of a shmem/tmpfs file is limited by the maximum size of
 * its triple-indirect swap vector - see illustration at shmem_swp_entry().
 *
 * With 4kB page size, maximum file size is just over 2TB on a 32-bit kernel,
 * but one eighth of that on a 64-bit kernel.  With 8kB page size, maximum
 * file size is just over 4TB on a 64-bit kernel, but 16TB on a 32-bit kernel,
 * MAX_LFS_FILESIZE being then more restrictive than swap vector layout.

Um oitavo de 2 TB é exatamente 256 GB. Tamanhos maiores são possíveis com um kernel de 32 bits, como você descobriu com seu sistema de teste FC6 de 32 bits.

Parece que alterar o tamanho da página pode estar relacionado a permitir Suporte para o sistema de arquivos BigTLB no kernel. No entanto, eu não sei o suficiente sobre as entranhas do kernel para dizer como ou por que, ou quais etapas você precisa tomar para tirar vantagem disso, ou quais outras implicações podem ter. Para ativá-lo, execute make menuconfig , navegue para Sistemas de arquivos e, em seguida, Pseudo filesystems . A opção em questão é suporte ao sistema de arquivos HugeTLB . A ajuda on-line para isso diz:

CONFIG_HUGETLBFS:

hugetlbfs is a filesystem backing for HugeTLB pages, based on
ramfs. For architectures that support it, say Y here and read
<file:Documentation/vm/hugetlbpage.txt> for details.

If unsure, say N.

Pode valer a pena executá-lo também pelo StackOverflow. Espero que isso ajude.

    

Answer 2

Uma sugestão ... você poderia criar uma imagem ext3 no tmpfs e montá-la, e colocar o lastlog nela? Algo como:

cd /tmp
dd if=/dev/zero of=lastlog.img bs=1024k count=10
losetup /dev/loop1 lastlog.img
mkfs.ext3 /dev/loop1
mount /dev/loop1 /var/lastlog