Sridhar Sarnobat's questions

Tenho um NUC10i7FNH1 e estou tentando usar um dock USB HDD para ler minhas unidades SATA de 6 TB ou 12 TB via USB.

As unidades funcionaram bem no meu PC ATX, mas quando as levo para a estrada com meu NUC, nada é detectado no BIOS (eu configurei o AHCI, que o Google sugeriu; além disso, meu MacBook Pro M3 não detecta nenhum dispositivo).

Depois de fazer muita solução de problemas tentando diferentes combinações de hardware, estou chegando à conclusão de que as placas-mãe de mini PCs simplesmente não conseguem lidar com essa densidade de disco rígido (mesmo que os docks USB tenham sua própria fonte de alimentação). É esse o caso?

Em outras palavras, existe alguma limitação prática no uso de um Raspberry Pi como um servidor de arquivos NAS simples para discos SATA maiores?

Suponha que eu esteja esperando a conclusão de um comando de longa execução.

Antes eu conseguia digitar o segundo comando, e o texto digitado era preservado quando o primeiro comando era concluído e o prompt retornava (e até mesmo executava o segundo comando se eu tivesse pressionado Enter).

Isso não acontece mais e não me lembro de atualizar o zsh, o cliente iTerm Mac OS ou qualquer coisa no meu servidor Ubuntu.

Não tenho certeza do que pesquisar no Google, não consigo pensar em quais termos de pesquisa usar. E minhas tags podem ser enganosas. Espero que alguém possa me apontar a direção certa

Exemplo A: 2º comando executado

Desejado

$ sudo zfs create -o mountpoint=/media/me/disk pool_my/disk
(long pause)sudo chown me /media/me/disk<enter>
$ ls -ld /media/me/disk
drwxr-xr-x 2 me me 2 Sep 18 21:37 /media/sarnobat/videos_10G

Real

$ sudo zfs create -o mountpoint=/media/me/disk pool_my/disk
(long pause)sudo chown me:me /media/me/disk<enter>
$ ls -ld /media/me/disk
drwxr-xr-x 2 root root 2 Sep 18 21:37 /media/sarnobat/videos_10G

O 2º comando não foi executado.

Exemplo B: 2º texto de comando preservado

Desejado

$ sudo zfs create -o mountpoint=/media/me/disk pool_my/disk
(long pause)sudo chown me /med
$ sudo chown me /med

Real

$ sudo zfs create -o mountpoint=/media/me/disk pool_my/disk
(long pause)sudo chown me /med
$ 

O comando incompleto que comecei a digitar antes do comando anterior terminar desapareceu.

Estou descobrindo que a capacidade de resposta do meu Macbook Air mais antigo e mais lento no Microsoft Remote Desktop Client para o meu servidor Ubuntu é significativamente melhor do que a do meu Macbook Pro mais recente (por exemplo, clicar em uma janela GUI na minha sessão remota é registrado mais rapidamente no primeiro cliente; ambos use a mesma sessão de exibição X). Minha velocidade geral de internet em ambos os dispositivos é comparável.

Isso não faz sentido para mim - eles estão na mesma rede, têm uma versão principal semelhante do sistema operacional, o mesmo aplicativo cliente, etc. Na verdade, eu esperaria o contrário, ou seja, meu Macbook Air será mais lento.

Eu sei que esta é uma pergunta vaga, mas qual seria o ponto de partida para solucionar isso? Eu sei como solucionar problemas de conectividade com netcat, ping etc., mas isso é estranho.

Outras notas:

• Eu costumava usar o Macbook Pro mais recente para trabalhar, que tinha vários perfis de segurança instalados. Mas removi todos eles e não vejo nenhuma evidência em outro comportamento de que existam resquícios de alguma nuvem privada. E não estou expondo publicamente a porta RDP, então duvido que tome um caminho diferente.

Quando instalo experimentalmente algum software novo, não faço o esforço extra de colocar todos os ativos nos lugares certos, como arquivos /usr/local/man.

Ocasionalmente, gostaria de ter suporte de página de manual para ele, mas não quero sobrecarregar minha instalação básica do Linux com ele (depois de alguns meses, a nova ferramenta cai em desuso). Para binários, isso não é um problema porque $PATH pode ser anexado onde quer que eu coloquei meu executável de curto/médio prazo. Mas existe um equivalente para manativos?

(pensando bem, não tenho 100% de certeza de qual é a diferença entre doce e man, mas presumo que manseja o que é pesquisado por apropos, o que irritantemente me dá zero resultados para quase tudo)

Eu sei que rsynccom --remove-source-files(que eu uso em vez de mvpara poder mesclar hierarquias de diretórios) cria novos inodes:

stat 2021_07_30_20_18_17.pdf~
rsync --remove-source-files 2021_07_30_20_18_17.pdf~ 2021_07_30_20_18_17.pdf~.moved
stat 2021_07_30_20_18_17.pdf~.moved

Device: 805h/2053d  Inode: 4850411     Links: 1
Device: 805h/2053d  Inode: 4849693     Links: 1

Como está alocando um novo inode, isso significa que ele aloca novo espaço para o arquivo de destino? Ou --remove-source-filesapenas faz o novo inode apontar para os locais de memória do arquivo original?

Fundo

A razão pela qual estou perguntando é porque tenho uma unidade muito lenta devido a enormes hierarquias de diretórios com arquivos grandes e pequenos misturados) e acho que isso piora a fragmentação. Como a maioria dos sistemas de arquivos Linux não sofre fragmentação, não existe uma ferramenta simples para desfragmentar como no Windows.

Eu sei que posso rsync para uma nova unidade para reduzir a fragmentação, mas e para a mesma unidade? A movimentação de arquivos funciona da mesma maneira do ponto de vista de alocação de memória?

Realizo várias tarefas sysadmin para limpar meus discos, como (mas não limitado a):

find /media/me/disk_with_huge_inode_count -type d -empty | xargs rmdir -p

e a rmdirpeça é muito lenta, enquanto findproduz uma enorme quantidade de saída em comparação.

Qual seria o comportamento do findsob tal cenário?

Não procuro aconselhamento específico para esta operação porque tenho esta preocupação com outros trabalhos semelhantes. O que eu quero entender é como o kernel Linux (ou shell?) lida com estouros de pipeline quando o produtor e o consumidor têm uma incompatibilidade de carga.

No Linux, obtenho cores bonitas que facilitam a distinção entre o nome do arquivo e os números de linha do conteúdo do arquivo:

Eu configurei GREP_COLORSno Mac OS X para minha instalação do GNU grep (via homebrew), mas ela é ignorada. Acabei de obter a coloração do texto correspondente, que é mais limitado.

Informação da versão

/Volumes/numerous/usr/local/homebrew/opt/grep/libexec/gnubin/grep --version
grep (GNU grep) 3.7
Packaged by Homebrew
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others; see
<https://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.

GREP_COLORS='ms=01;31:mc=01;31:sl=:cx=:fn=35:ln=32:bn=32:se=36'

Resposta incorreta

Usar --color=always. Não estou falando de destacar partidas. Estou falando de coloração de componentes.

Quando mudo de VPN ou fecho meu laptop, minha conexão ssh é interrompida - o que é aceitável. MAS quero ser lembrado do que estava fazendo na última execução (geralmente estou usando o rsync para mover arquivos).

Mas quando executo historyesses comandos não aparecem. Embora eu não saiba exatamente quando o zsh confirma o histórico, parece que ele não o grava .zsh-historyassim que o comando é invocado.

O ZSH tem uma maneira de adicionar comandos .zsh-historyimediatamente?

Outras informações

Lembro-me vagamente de definir uma variável que compartilha o histórico entre as guias, mas não consigo encontrá-la (aparentemente, isso não é suficiente). Isso não retorna nada:

env | grep HIST

Eu executo um comando incorreto sobre ssh:

watch /bin/df | grep _23

Agora eu executo um comando como enve recebo isso:

LC_TERMINAL_VERSION=3.3.4
                         LC_TERMINAL=iTerm2
                                           LC_CTYPE=en_US.UTF-8
                                                               LC_COLLATE=en_US.UTF-8
                                                                                     LC_MESSAGES=en_US.UTF-8
                                                                                                            LC_MONETARY=en_US.UTF-8
                                                                                                                                   LC_NUMERIC=en_US.UTF-8
                                                                                                                                                         LC_TIME=en_US.UTF-8
                                                                                                                                                                            LC_ALL=en_US.UTF-8
                                                                SHELL=/usr/bin/zsh                                                                                                                                                                        SSH_TTY=/dev/pts/26
   TERM=xterm-256color
                      DISPLAY=localhost:16.0
                                            XDG_SESSION_ID=18040
                                                                XDG_RUNTIME_DIR=/run/user/1000
                                                                                              SHLVL=1

Parece que o separador de linha de saída é um avanço de linha, mas não um retorno de carro.

Mas não tenho certeza se isso só acontece por ssh. Acho que já vi esse comportamento depois de usar vimtambém.

Por que isso acontece e qual é a maneira mínima de redefini-lo? Eu costumo correr, source ~/.zshrcmas isso é um exagero.

Faz o que eu espero

• cat <(shuf my_ordered_playlist.m3u)
• echo <(shuf my_ordered_playlist.m3u)
• vlc my_ordered_playlist.m3u

Não faz o que eu espero

• vlc <(shuf my_ordered_playlist.m3u)

O que eu quero fazer

• Reproduza os elementos da minha lista de reprodução em uma ordem não determinística em cada invocação de vlc e
• ser capaz de retroceder ao pressionar o botão Voltar (que --randomfornece um suporte ruim para).

Outras notas

• Posso conseguir o que quero com um documento aqui ou <<<?