Como criar um ramdisk Linux de tamanho fixo que nunca troca para o disco?

8

Eu quero criar um ramdisk Linux de tamanho fixo, que nunca troca no disco. Note que minha pergunta não é "por que" eu quero fazer isso (digamos, por exemplo, que seja para um propósito educativo ou para pesquisa): a questão é como fazê-lo.

Pelo que entendi, ramfs não pode ser limitado em tamanho, então não se encaixa na minha exigência de ter um disco em disco de tamanho fixo.

Também parece que tmpfs pode ser trocado para o disco. Por isso, não se encaixa na minha exigência de nunca trocar para o disco.

Como você pode criar um ramdisk Linux de tamanho fixo que nunca troca para o disco?

É possível, por exemplo, criar tmpfs dentro de um ramfs (essa solução se ajustaria aos meus requisitos) e, em caso afirmativo, como?

Note que as performances não são um problema e o ramdisk está cheio e os erros de "disco cheio" também não são um problema.

    
por user57725 27.01.2014 / 15:20

3 respostas

5

Isso é apenas um pensamento e tem mais de uma desvantagem, mas pode ser útil o suficiente de qualquer maneira.

Que tal criar um arquivo de imagem e um sistema de arquivos dentro dele em cima dos ramfs e montar a imagem como um dispositivo de loop? Dessa forma, você pode limitar o tamanho do ramdisk simplesmente limitando o tamanho do arquivo de imagem. Por exemplo:

$ mkdir -p /ram/{ram,loop}
$ mount -t ramfs none /ram/ram
$ dd if=/dev/zero of=/ram/ram/image bs=2M count=1
1+0 records in
1+0 records out
2097152 bytes (2.1 MB) copied, 0.00372456 s, 563 MB/s
$ mke2fs /ram/ram/image
mke2fs 1.42 (29-Nov-2011)
/ram/ram/image is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
256 inodes, 2048 blocks
102 blocks (4.98%) reserved for the super user
First data block=1
Maximum filesystem blocks=2097152
1 block group
8192 blocks per group, 8192 fragments per group
256 inodes per group

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done
$ mount -o loop /ram/ram/image /ram/loop
$ dd if=/dev/zero of=/ram/loop/test bs=1M count=5
dd: writing '/ram/loop/test': No space left on device
2+0 records in
1+0 records out
2027520 bytes (2.0 MB) copied, 0.00853692 s, 238 MB/s
$ ls -l /ram/loop
total 2001
drwx------ 2 root root   12288 Jan 27 17:12 lost+found
-rw-r--r-- 1 root root 2027520 Jan 27 17:13 test

No exemplo (um pouco longo demais) acima, o arquivo de imagem é criado para ter 2 megabytes e ao tentar gravar mais de 2 megabytes nele, a gravação simplesmente falha porque o sistema de arquivos está cheio.

Uma desvantagem óbvia para tudo isso é, claro, que há muita complexidade adicional, mas pelo menos para fins acadêmicos isso deve ser suficiente.

    
por 27.01.2014 / 16:16
1

O (antiquado) livro "Drivers de Dispositivos Linux" da Corbet, Rubini e Kroah-Hartman tem um exemplo de driver que apenas aloca uma área de memória fixa para brincar. Não é um sistema de arquivos, mas ...

    
por 30.01.2014 / 15:26
-1

Não pode ser feito. Toda a RAM está sujeita a paginação pelo design de hardware da CPU e pelo design do microkernel do Linux. Não existem razões legítimas para tratar a memória de outra forma. TODOS os algoritmos de software PODEM ser adaptados para usar o esquema de armazenamento em cache de arquivos e a memória paginada. Virtual é SEMPRE melhor e mais eficiente.

Discos RAM de tamanho limitado vão contra os princípios fundamentais do mundo virtual. Você deve assumir que apenas solicitações de arquivos úteis estão sendo feitas para o sistema de arquivos do host e que todas essas solicitações têm igual importância e prioridade no mundo virtual (o único modelo que conta).

Está matematicamente provado que mesmo os processos em tempo real se encaixam nessa regra. Se você tiver um problema de velocidade, ele NÃO PODE ser resolvido usando RAM como armazenamento == todo o sistema host precisa operar mais rápido da CPU para o barramento de E / S para o dispositivo de armazenamento permanente. Todos, exceto os problemas de computação degenerados artificiais, possuem ramificações e requisitos de I / O suficientes para que o aumento médio de velocidade do armazenamento em cache de RAM seja o melhor que você pode fazer.

    
por 09.05.2018 / 01:26