GraemeV's questions

Originalmente, mv(1)era uma operação de renomeação; atualizava nomes em sistemas de arquivos e não copiava arquivos. Mais recentemente, um recurso de conveniência foi adicionado, pelo qual se a origem e o destino estivessem em sistemas de arquivos diferentes, ele copiaria e excluiria os arquivos. Também conhecido como "inter-device move".

Agora eu estava tentando arrumar meus backups. Eu queria mudar .../rest2/Public/Backupspara .../rest2/Backup/(Backups), então:

root@ts412:/QNAP/mounts/rest2# mv Public/Backups Backup/  

Onde:

root@ts412:/QNAP/mounts/rest2# df -h /QNAP/mounts/rest2/Public/                                                                                                                                                                          
Filesystem      Size  Used Avail Use% Mounted on                                                                                                                                                                                         
/dev/sdb10      831G  715G   75G  91% /QNAP/mounts/rest2                                                                                                                                                                                 
root@ts412:/QNAP/mounts/rest2# df -h /QNAP/mounts/rest2/Backup/                                                                                                                                                                          
Filesystem      Size  Used Avail Use% Mounted on                                                                                                                                                                                         
/dev/sdb10      831G  715G   75G  91% /QNAP/mounts/rest2

Então, o mesmo sistema de arquivos:

(Para sua informação, rest2é "o resto do espaço em disk2")

Mas a mudança começou a se comportar como uma "mudança entre dispositivos" (alta CPU, discos ocupados, vários erros sobre diretórios não vazios etc.), então eu a eliminei.

Verificando de uma forma ligeiramente diferente (observe o .):

root@ts412:/QNAP/mounts/rest2# df -h Backup/.                                                                                                                                                                                            
Filesystem      Size  Used Avail Use% Mounted on                                                                                                                                                                                         
/dev/sdb10      831G  715G   75G  91% /QNAP/mounts/rest2                                                                                                                                                                                 
root@ts412:/QNAP/mounts/rest2# df -h Public/Backups/.                                                                                                                                                                                    
Filesystem      Size  Used Avail Use% Mounted on                                                                                                                                                                                         
/dev/sdb10      831G  715G   75G  91% /QNAP/mounts/rest2/Public  

Então eu lembro que EU TAMBÉM tinha um bind mount (ele torna os nomes compartilhados via NFS mais amigáveis). Então eu desmontei o bind mount extra:

root@ts412:/QNAP/mounts/rest2# umount /QNAP/mounts/rest2/Public                                                                                                                                                                          
root@ts412:/QNAP/mounts/rest2# df -h Public/Backups/.                                                                                                                                                                                    
Filesystem      Size  Used Avail Use% Mounted on                                                                                                                                                                                         
/dev/sdb10      831G  715G   75G  91% /QNAP/mounts/rest2                                                                                                                                                                                 
root@ts412:/QNAP/mounts/rest2# mv Public/Backups Backup/   

E mv(1)foi instantâneo, como eu esperava.

Então, apesar dos s extras mount(8), a fonte e o alvo sempre estavam no mesmo sistema de arquivos , o que mount -o bind /QNAP/mounts/rest2/Backups /Backupsnão afeta isso. Então, estou pensando se mv(1)obtém pontos de montagem de volta /QNAP/mounts/rest2 para um e /QNAP/mounts/rest2/Publicpara o outro, ele decide incorretamente que os dois arquivos estão em sistemas de arquivos diferentes?

Estou tentando limpar algum código C e construir um pacote Debian. O makefile foi configurado para usar -Wall mas debuild usa -Wpedantic .

Acontece que isso foi "uma coisa boa", pois o código estava lançando ponteiros de dados em ponteiros de função (não permitido em ISO C e seriamente perigoso ... em algumas arquiteturas, os dados e o código podem estar em espaços de endereço diferentes)

No entanto, o código também usa intervalos em instruções switch, estas são uma extensão gcc (e clang) e então -Wpedantic dá um ajuste.

case QNAP_PICSTS_SYS_TEMP_0 ... QNAP_PICSTS_SYS_TEMP_70:

(#define não é um enum)

Eu suponho que o uso de intervalos de switch é comum no kernel, eu poderia recodificá-lo para usar um padrão com alguma lógica if/else, mas isso será realmente mais lento (uma tabela de salto versus código)

Então, 1 existe uma opção para permitir apenas esse recurso e 2 (para ganhar pontos extras) como faço para definir isso nas regras do pacote Debian?

As opções estão aqui:

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Warning-Options.html

Estou executando o Debian Bookworm em um TS412 (QNAP); ele armazena o kernel e o initrd em flash. Tem um total de 16 MB de flash. Portanto, mesmo depois de ajustar as partições MD, o melhor que consigo é um initrd de 12 MB. Estou usando compactação xz. Mas mesmo assim, o initrd inicial era de 12,5 MB. Eu sei que a solução comum é reduzir os módulos, mas eles não são o verdadeiro problema.

2984    .../usr/lib/modules
6036    .../usr/share
18824   .../usr/lib/arm-linux-gnueabi

Procurando em arm-linux-gnueabi tinha coisas como libX11... Essa máquina nem tem console (até conseguir uma linha serial é difícil) certamente não precisa de "X".

Então eu removi muitos pacotes totalmente (apt-get remove ...), na verdade, um pouco mais do que deveria. Mas o resultado foi um initrd muito menor (cerca de 5 MB IIRC) que inicializa e funciona perfeitamente.

O problema é que, se eu fizer ssh na caixa e executar o emacs(1), seria bom projetar a versão da GUI de volta para minha área de trabalho normal (que tem muita memória e telas grandes, etc.), mas isso exigiria a instalação do Bibliotecas cliente X no TS412.

Agora não vejo por que só porque tenho o pacote com as bibliotecas do cliente X instaladas, uma cópia precisa ser mantida no initrd, elas não são necessárias durante a inicialização. Existe uma maneira de limitar a entrada de outras coisas no initrd, não apenas nos módulos (que não são os culpados)

Já tentei pesquisas em documentos em busca de guias para limitar o initrd.

Acabei de ter uma série de problemas com a inicialização do meu sistema Debian (SID), de repente ele relatou:

/grub/i386-pc/normal.mod not found.

Eventualmente, eu o recuperei (fsck moveu muitas coisas de /boot para lost+found e precisei substituir via grub-install)

Mas depois que tudo estava funcionando e eu reinstalei vários pacotes grub-* (caso eles estivessem agora em achados e perdidos). Percebi que o grub.cfg tinha muitas diferenças, da forma:

<               set root='hd2,msdos1'                                                                                                                                                                
---                                                                                                                                                                                                  
>               set root='hd0,msdos1'                                                                                                                                                                
  

                        

Na verdade, meu dispositivo /boot (e / (root)) agora era /dev/sdc (hd2) e não /dev/sda (hd0). Por um lado, não consigo ver como/por que mudou, mas, por outro lado, percebo que o nome /dev/sdX não é fixo e PODE mudar de uma inicialização para a outra. Então, diante de tudo isso, minha pergunta é:

Como o grub.cfg pode conter entradas como:

set root='hd2,msdos1'

Como (não há arquivo de mapeamento) isso equivale a /dev/sdc ...e se na próxima inicialização esse disco aparecer como sdb ou sda ?

ABTW. A causa inicial provavelmente foi corrompida /boot ... Percebo que é ext2 , não posso usar ext4? ... e esse não é o padrão agora? [Bug 985470 ]

Agora estamos todos familiarizados com não usar:

find . -print | xargs cmd

mas usando

find . -print0 | xargs -0 cmd

Para lidar com nomes de arquivos contendo, por exemplo, nova linha, mas e uma linha que tenho em um script:

find $@ -type f -print | while read  filename

Bem, imaginei que seria algo como:

find $@ -type f -print0 | while read -d"\0" filename

E se eu simplesmente tivesse feito:

 find $@ -type f -print0 | while read filename

Eu estaria vendo os NULLs?

Mas não, o loop while sai após zero vezes (em ambos os casos) eu assumo porque a leitura retornou zero, também assumo porque leu um NULL (\0) .

Parece que a leitura do bash deve ostentar uma opção "-0" .

Eu interpretei mal o que está acontecendo ou há uma maneira diferente de enquadrar isso?

Para este exemplo, posso muito bem ter que recodificar para usar xargs, mas isso é um monte de novos processos que não queria bifurcar.