Tiago Pimenta's questions

Para montar a sobreposição é dado lowerdir, upperdire workdircomo opções em mount(8) ou dados em mount(2) , qual lógica é aplicada para escapar de vírgulas? Eu tentei vírgulas duplas e até citando sem sucesso.

Há duas soluções alternativas que descobri que não são exatamente o que eu quero:

1. Caminho relativo: desde que o último componente não tenha vírgulas o seguinte funciona:

   mkdir /tmp/a,b /tmp/a,b/{upper,lower,work,merged}
   cd /tmp/a,b
   sudo mount \
     -t overlay \
     -o 'lowerdir=./lower,upperdir=./upper,workdir=./work' \
     overlay \
     '/tmp/a,b/merged'
   

   Mas reforço que não funciona se o último componente contiver vírgulas.

2. Mover o caminho após a montagem: acredito que o kernel mantenha o inodecontrole, pois os valores da opção /proc/self/mountinfonão mudam:

   mkdir /tmp/a\ b /tmp/a\ b/{upper,lower,work,merged}
   sudo mount \
     -t overlay \
     -o 'lowerdir=/tmp/a b/lower,upperdir=/tmp/a b/upper,workdir=/tmp/a b/work' \
     overlay \
     '/tmp/a b/merged'
   mv '/tmp/a b' '/tmp/a,b'
   fgrep merged /proc/self/mountinfo
   314 86 0:56 / /tmp/a,b/merged rw,relatime shared:217 - overlay overlay rw,lowerdir=/tmp/a\040b/lower,upperdir=/tmp/a\040b/upper,workdir=/tmp/a\040b/work
   

Nota : Como o kernel escapa de espaço, tabulação, novas linhas e caracteres de barra invertida com três dígitos decimais, também tentei escapar de vírgula \044sem sucesso, parece que ele quer escapar de barra invertida novamente.

Eu clonei um disco em um arquivo esparso que tem cerca de 80G, mas na verdade requer apenas cerca de 12G, mesmo não compactado, cabe na minha memória, mas para economizar alguns recursos, quero usar zram :

sudo modprobe zram num_devices=1
echo 79999997952 | sudo tee /sys/block/zram0/disksize
sudo fdisk -c=dos --sector-size 512 /dev/zram0

No entanto, quando crio a partição, ela está usando o tamanho do setor 4096, mesmo que eu disse ao fdisk para usar 512.

Ele não me permite digitar o tamanho da partição com base no tamanho do setor 512, e não é um número exato que eu poderia dividir por 8 para ter um baseado em 4096, então fiz em um mbr esparso :

truncate -s79999997952 /tmp/block
fdisk -c=dos --sector-size 512 /tmp/block
# o, n, p, 1, 63, 156232124, t, 7, a, w
sudo dd if=/tmp/block of=/dev/zram0 count=1 bs=512

Parece que com arquivos regulares o fdisk não vê problema em usar um tamanho de setor de 512! Mas o zram ainda é estranho, não sei se vai funcionar, pois mostra um tamanho de disco diferente quando no modo 512:

$ sudo fdisk -lu /dev/zram0
Disk /dev/zram0: 74.5 GiB, 80000000000 bytes, 19531250 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x5f8b6465

Device       Boot Start       End   Sectors  Size Id Type
/dev/zram0p1 *       63 156232124 156232062  596G  7 HPFS/NTFS/exFAT


$ sudo fdisk -lu --sector-size 512 /dev/zram0
Disk /dev/zram0: 9.3 GiB, 10000000000 bytes, 19531250 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x5f8b6465

Device       Boot Start       End   Sectors  Size Id Type
/dev/zram0p1 *       63 156232124 156232062 74.5G  7 HPFS/NTFS/exFAT

Entenda, uma vez 156232062 / 8 = 19529007.75que não há como caber no tamanho do setor 4096.

Como forçar o fdisk ou o próprio zram a usar o tamanho do setor 512?

O script de shell permite vários descritores de arquivo (até 9 para conformidade com POSIX, mas ainda mais para bash):

$ install -m 755 /dev/stdin /tmp/test <<\EOF
#!/bin/sh

echo hi1 >&1
echo hi2 >&2
echo hi3 >&3
echo hi4 >&4
EOF
$ /tmp/test 1> /tmp/1 2> /tmp/2 3> /tmp/3 4> /tmp/4
$ cat /tmp/1
hi1
$ cat /tmp/2
hi2
$ cat /tmp/3
hi3
$ cat /tmp/4
hi4

Eu quero alcançar o mesmo comportamento no SSH, mas o que acontece é:

$ ssh user@remote_machine /tmp/test 1> /tmp/1 2> /tmp/2 3> /tmp/3 4> /tmp/4
$ cat /tmp/1
hi1
$ cat /tmp/2
hi2
/tmp/test: 5: /tmp/test: 3: Bad file descriptor
/tmp/test: 6: /tmp/test: 4: Bad file descriptor
$ cat /tmp/3
$ cat /tmp/4

É possível ter vários tubos de saída sobre SSH além de stdoute stderr?

É importante observar que não estou procurando por encaminhamento de porta, pois terei problemas de rede.

Quando uso o LVM para particionar um ou mais armazenamentos, noto que ele usa blocos de 4 MiB' (extensão física) por padrão, enquanto o próprio armazenamento geralmente usa 512 bytes por setor.

Eu acreditava que não deveria ser um problema se eu alinhar as partições LVM para 4 MiB, mas não importa o tamanho que elas sejam, sempre mostrará algum tamanho "não utilizável" quando executado pvdisplay:

--- Physical volume ---
PV Name               /dev/sda2
VG Name               xpto
PV Size               17.00 GiB / not usable 4.00 MiB
Allocatable           yes (but full)
PE Size               4.00 MiB
Total PE              4351
Free PE               0
Allocated PE          4351
PV UUID               xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx

Mas mesmo se eu realocar o PV para corresponder ao tamanho menos o não utilizável, ele diminuirá o PE total e ainda terá o tamanho restante não utilizável. Mesmo usando pvdisplay --unit Bpara ver o número exato.

Estou querendo saber qual o tamanho exato do cabeçalho LVM, li algum texto argumentando que seriam 4 setores de 512 bytes, outros dizendo que são 180 KiB, mas já tentei todas as combinações e não consegui descobrir como é calculado.

Existe uma maneira de alinhar a partição PV para zerar o tamanho não utilizável, ou pelo menos reduzir ao mínimo?

Estou escrevendo um script que gera um screenprocesso, mas depende de algumas pré-condições que pretendo executar antes de anexar a ele.

Percebi que quando iniciado em modo desanexado ele não reconhece o $TERM, mas não quero codificá-lo no .screenrc, e não encontrei ninguém com o mesmo problema.

Segue meu ambiente:

$ screen --version
Screen version 4.06.02 (GNU) 23-Oct-17
$ echo $TERM
xterm-256color

Aqui você pode ver que funciona como esperado:

$ screen -ADRS profile
$ echo $TERM
screen.xterm-256color

Mas se for feito assim dá tudo errado:

$ screen -dmS profile
# I will perform some stuff here, then:
$ screen -ADrS profile
# here you can notice the colors have gone
$ echo $TERM
screen

Como posso gerar um desanexado screen, mas obter o mesmo $TERMcomportamento do primeiro caso, sem codificar o termo em .screenrc?

Eu tenho um servidor Linux em uma VM que a reinicialização funciona como desligamento devido à configuração incorreta de um provedor de terceiros. Não tenho acesso à configuração da VM.

A pessoa que instalou o sistema fez uma bagunça com o armazenamento e montou irresponsavelmente um ponto para cada diretório ( /var, /home, /usr, etc...) levando-os a serem facilmente famintos para alguns e vazios para outros.

Para consertar essa bagunça estou reorganizando os pontos de montagem, consegui gerenciar a maioria deles fazendo mount --bind / /mntseguido rsynce depois relançando o processo que os usa depois umount.

O problema é o /vare /usrque é usado pelo próprio processo de inicialização do systemd. Será systemd-remount-fsque o truque? Como eu poderia permorr isso? Seria uma simples fstabedição seguida de rsyncser suficiente? Ele reiniciará todos os serviços?

Eu sei quais pontos realmente precisam de partições separadas para o meu caso, e não é o caso de /vare de jeito /usrnenhum.

A premissa é que não posso usar umount -l, pois terei que destruir a partição depois de remontar a mesma, e gostaria de evitar kexecpor não saber se ela terá o mesmo efeito de bug nessa VM mal configurada de não conseguir trazê-la novamente .

Estou planejando ter uma btrfspartição compactada para /var/loge outra btrfsou xfspara /var/lib/docker, e juntar todas as outras com o mínimo de espaço necessário possível uma vez que elas ficarão quase estáticas. E no futuro eu posso colocá-los squashfsjunto com o root e montar um overlayfspara facilitar a detecção de configurações incorretas. Eu gostaria de poder fazer tudo isso sem reiniciar, embora eu não saiba se poderei.

Eu queria saber como o Linux poderia lidar com um Gamer Computer, então construí um, mas como sabemos que a GeForce não gosta tanto do Linux quanto da AMD, por isso escolhi o último.

Montei um computador com CPU AMD Ryzen 7 1800X e GPU Radeon RX 560D, pois o Vega é muito caro para eu comprar, e o benchmarking dizia que 560 é o melhor custo benefício atualmente.

Depois de algumas pesquisas, descobri que o sufixo D significa que ele tem um pouco menos de clock para economizar algum consumo de energia em comparação com o RX560 sem D.

Depois de inúmeras falhas durante jogos aleatórios, finalmente descobri que o problema é o superaquecimento da GPU, a velocidade do ventilador tende a seguir a velocidade do ventilador da CPU, mas é claro que a CPU é muito menos necessária do que a GPU em alguns jogos.

Resolvi parcialmente o problema personalizando a velocidade do ventilador com base na temperatura da GPU em vez da CPU, agora está crescendo gradativamente e atinge a velocidade máxima em 50 graus Celsius, mas o problema é: em alguns jogos ele mantém a velocidade máxima o tempo todo , e eventualmente ainda trava.

Descrevendo a falha: a tela pisca e depois fica preta, o ventilador da GPU para, o led do teclado pisca e depois desliga, mouse o mesmo, outro ventilador da CPU continua, às vezes o sistema fica congelado para sempre, às vezes o sistema reinicia automaticamente.

Como uma reinicialização é necessária, não consegui encontrar nenhuma dica nos logs do sistema, inicialmente pensei que fosse um pânico do kernel, mas mesmo usando o kdump e duplicando o kernel, o sistema ainda trava da maneira que não consegui recuperá-lo.

Não sei se o Windows teria o mesmo problema, mas acredito fortemente que não, nunca vi alguém com o mesmo problema no Windows, então minha dúvida é: existe alguma forma de dizer ao kernel para fazer a GPU pegar leve quando está prestes a superaquecer, talvez apenas reduzindo automaticamente a velocidade do clock da GPU?