Marcos FRM

Aham. btrfs-progs 6.1 ainda é bem recente, então só funcionará em Linuxes atuais. Com o passar do tempo, será feijão com arroz. "btrfs inspect-internal map-swapfile -r /arquivo" funciona direito, já testei.

Não funciona. O valor retornado pela ioctl no Btrfs é fajuto: https://bugzilla.kernel.org/show_bug.cgi?id=202803#c3

Pode apagar totalmente o SSD de 240 GB?

Sim, tem algo não muito bem documentado nisso. Eu chuto que, quando sistema está muito desatualizado, o Windows Update entra num modo "agora não tem aviso coisa nenhuma" e age assim. Porém, ao manter as coisas em dia, com as atualizações sendo aplicadas mês a mês como é para ser, sempre recebi o aviso na área de notificação e as opções adicionais no menu desligamento (Windows 10 aqui).

Mais uma correção: o "formato" swap de que falei antes é mantido apenas na memória, enquanto o arquivo de swap está ativo (entre swapon(2) e swapoff(2)). A árvore de swap_extent não é gravada no disco. Hibernação usa outro código: https://github.com/torvalds/linux/blob/v6.3/kernel/power/swap.c Ao hibernar, o arquivo de swap é desativado; o kernel então faz uma imagem da RAM e grava no arquivo de swap, substituindo o cabeçalho para na próxima inicialização saber que tem que acordar a partir dele. Essa imagem é um sistema de arquivos rudimentar escrito no disco, que consegue "pular" as diversas descontinuidades que eventualmente compreendam o arquivo. Depois de acordado, o kernel restaura o cabeçalho e reativa o arquivo de swap. Fascinante ficar garimpando no código, muitas vezes entendendo muito pouco do que tem lá... kkk.

Agora aconteceu comigo. O fórum esteve instável e, quando voltou, adeus VIP...

Errado. Corrigindo a informação... Este arquivo de 96 GB, dentro de XFS, criado com fallocate(1), tem extents descontínuos e mesmo assim é aceito pelo kernel: # filefrag -v /swap Filesystem type is: 58465342 File size of /swap is 103079215104 (25165824 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 0: 133684.. 133684: 1: 1: 1.. 2097150: 133685.. 2230834: 2097150: unwritten 2: 2097151.. 4194301: 2230835.. 4327985: 2097151: unwritten 3: 4194302.. 6291452: 4327986.. 6425136: 2097151: unwritten 4: 6291453.. 8388603: 8489853.. 10587003: 2097151: 6425137: unwritten 5: 8388604..10485754: 10587004.. 12684154: 2097151: unwritten 6: 10485755..12582905: 12684155.. 14781305: 2097151: unwritten 7: 12582906..14680056: 16850563.. 18947713: 2097151: 14781306: unwritten 8: 14680057..16777207: 36355047.. 38452197: 2097151: 18947714: unwritten 9: 16777208..18874358: 28036702.. 30133852: 2097151: 38452198: unwritten 10: 18874359..20971509: 30133853.. 32231003: 2097151: unwritten 11: 20971510..23068660: 32231004.. 34328154: 2097151: unwritten 12: 23068661..25165811: 19682561.. 21779711: 2097151: 34328155: unwritten 13: 25165812..25165823: 21779712.. 21779723: 12: last,unwritten,eof /swap: 6 extents found # dmesg | grep -w /swap [ 10.404033] systemd[1]: Activating swap /swap... [ 10.763899] Adding 100663292k swap on /swap. Priority:-2 extents:6 across:153274052k FS Meu programinha tabajara está ok: # ./a.out /swap 133684 Como o kernel escreve diretamente no dispositivo, sem ajuda do sistema de arquivos, no momento em que o arquivo é ativado (swapon(2)), o driver do sistema de arquivos[*] reúne os intervalos dos extents e diz ao gerenciador de memória que pode escrever entre os deslocamentos físicos A e B, C e D, etc. Descontinuidade é aceita pois o formato swap é um sistema de arquivos rudimentar também, baseado numa lista encadeada (árvore desde o 5.3) de estruturas swap_extent. Através desse esquema o kernel consegue mapear o arquivo de swap mesmo fragmentado. Este commit, que substituiu a lista encadeada, é útil para entender o mecanismo: https://github.com/torvalds/linux/commit/4efaceb1c5f8136d5fec3f26549d294b8e898bd7 --- [*] EXT4 e XFS (outros?) usam um código compartilhado para a tarefa: https://github.com/torvalds/linux/blob/v6.3/fs/iomap/swapfile.c (ver https://utcc.utoronto.ca/~cks/space/blog/linux/HowSwapFindsBlocks)

Ou adicione o caminho onde esse software fica na lista de exclusões.

Nas versões Pro e Enterprise é possível via GPO: https://www.tenforums.com/tutorials/5918-how-turn-off-microsoft-defender-antivirus-windows-10-a.html

Daí é tiro no escuro. O negócio pode ser uma maravilha, como pode ser um lixo, sem ter uma base para comparar. Qual das duas opções é mais provável deixo para a imaginação de cada um.

Qual é o melhor comparativo sério (e atualizado) de desempenho desses programas hoje? Ainda é o AV-Comparatives? Sem dados, a discussão é estéril.

Eu te afirmo que o programa funciona porque eu compilei e usei para obter com sucesso (hibernação testada depois) o deslocamento de meia dúzia de instalações, com variados tamanhos de arquivos (4GB a 16GB), em sistemas com EXT4 e XFS. Então, enquanto você não me demonstrar que não funciona, fica assim.

Não. Compile aí e teste num arquivo com centenas de extents.

O arquivo pode ter vários extents, mas precisam ser contíguos. Isso é mandatório, pois, do contrário, o kernel nem aceita (swapon() falha com EINVAL). Portanto, basta map->fm_extents[0].fe_physical (do primeiro extent) e pronto, pois, para a hibernação funcionar, o kernel apenas precisa saber onde o arquivo começa fisicamente no volume em questão. O resto obtém do cabeçalho posto pelo mkswap nos primeiros 4 KiB do arquivo. Nele, tem, entre outras informações, o número de páginas que compõem o arquivo.

Opa. struct fiemap tem um array flexível dentro; com --- antes.c 2023-05-18 10:05:04.374112514 -0300 +++ depois.c 2023-05-18 10:05:37.924002824 -0300 @@ -19,7 +19,7 @@ { int fd, r = EXIT_FAILURE; struct stat sb; - struct fiemap *map; + struct fiemap map; if (argc != 2) { @@ -46,16 +46,9 @@ goto fim; } - map = calloc(1, sizeof(struct fiemap) + sizeof(struct fiemap_extent)); - if (map == NULL) - { - perror("calloc"); - goto fim; - } - - map->fm_length = sb.st_size; - map->fm_flags = FIEMAP_FLAG_SYNC; - map->fm_extent_count = 1; // só interessa o primeiro extent + map.fm_length = sb.st_size; + map.fm_flags = FIEMAP_FLAG_SYNC; + map.fm_extent_count = 1; // só interessa o primeiro extent if (ioctl(fd, FS_IOC_FIEMAP, map) != 0) { @@ -63,11 +56,10 @@ } else { - printf("%llu\n", map->fm_extents[0].fe_physical / getpagesize()); + printf("%llu\n", map.fm_extents[0].fe_physical / getpagesize()); r = EXIT_SUCCESS; } - free(map); fim: close(fd); não funciona. Com alloca() daria, né? Mas, acabou o tédio para continuar. kkk

Isso pode ser desativado. https://www.tenforums.com/tutorials/48277-enable-disable-driver-updates-windows-update-windows-10-a.html Só não sei como fica nas versões Home. As atualizações são importantíssimas. Todas corrigem pencas de falhas de segurança. Numa instalação limpa, apenas a primeira atualização será mais demorada, pois os pacotes são diferenciais para economizar download. O mecanismo do Windows Update "monta" a atualização na sua máquina, usando como referência os arquivos da versão que estiver rodando no momento. Passada a atualização inicial, as próximas serão mais rápidas, pois a diferença será menor; costuma ser de um mês, que é o intervalo normal -- a menos que alguma falha muito grave apareça, daí a Microsoft antecipa. Eu mantenho uma batalha (acredito que perdida, infelizmente), junto com outros colegas aqui no fórum, para encorajar as pessoas a sempre manterem os sistemas atualizados. Esses dias estava lendo sobre uma falha do Windows em que a vulnerabilidade estava na pilha TCP/IP, no manuseio de pacotes TCP IPv6 fragmentados. A falha acontecia antes que qualquer firewall, antivírus ou o que for pudesse fazer qualquer coisa. Troço gravíssimo corrigido silenciosamente por um pacote mensal desses de atualização, que muitos acham ser "besteira", "bobagem", etc. Não é nada disso...

Tem que pesquisar. A Positivo usa placas remarcadas de tudo que é fabricante. Já vi da ASUS, da MSI, ...

Sim, com atualização volta o logotipo da marca. Cuide para usar o arquivo certo...

Estava lendo a wiki do Arch para configurar hibernação com arquivo de swap https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Hibernation_into_swap_file e este comando me embrulhou o estômago: filefrag -v /swapfile | awk '$1=="0:" {print substr($4, 1, length($4)-2)}' Para lidar com o tédio, escrevi isto que faz o mesmo, sem requerer bruxaria na saída: #define _FILE_OFFSET_BITS 64 // basename #define _GNU_SOURCE #include <fcntl.h> #include <linux/fiemap.h> #include <linux/fs.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/ioctl.h> #include <sys/stat.h> #include <unistd.h> // https://www.kernel.org/doc/Documentation/filesystems/fiemap.txt // https://www.kernel.org/doc/Documentation/power/swsusp-and-swap-files.txt int main(int argc, char **argv) { int fd, r = EXIT_FAILURE; struct stat sb; struct fiemap *map; if (argc != 2) { fprintf(stderr, "Uso: %s arquivo\n", basename(argv[0])); exit(EXIT_FAILURE); } fd = open(argv[1], O_RDONLY); if (fd < 0) { perror("open"); exit(EXIT_FAILURE); } if (fstat(fd, &sb) != 0) { perror("fstat"); goto fim; } if (!S_ISREG(sb.st_mode)) { fprintf(stderr, "Não é arquivo regular.\n"); goto fim; } map = calloc(1, sizeof(struct fiemap) + sizeof(struct fiemap_extent)); if (map == NULL) { perror("calloc"); goto fim; } map->fm_length = sb.st_size; map->fm_flags = FIEMAP_FLAG_SYNC; map->fm_extent_count = 1; // só interessa o primeiro extent if (ioctl(fd, FS_IOC_FIEMAP, map) != 0) { perror("ioctl FIEMAP"); } else { printf("%llu\n", map->fm_extents[0].fe_physical / getpagesize()); r = EXIT_SUCCESS; } free(map); fim: close(fd); return r; } Funciona com drivers de sistemas de arquivos que implementem FIEMAP -- menos o Btrfs. Leve o exit code em consideração, caso use num shell script: DESLOCAMENTO=$(programa /arquivo) || exit 1

A única saída seria um programador experiente fazer a engenharia reversa necessária, escrever o código (talvez aproveitando o que foi descoberto naquele tópico do fórum do Mint) e conseguir torná-lo "upstream", ou seja, fazer parte do kernel oficial. Assim, com o tempo, todas as distribuições passariam e ser compatíveis automaticamente. Idealmente, esse trabalho seria feito por engenheiros do OEM que projetou o hardware (que não foi a Positivo), ou, por algum milagre, por gente da Positivo. No entanto, como é hardware de baixíssimo custo, compatibilidade com o Windows deve ser o suficiente na visão deles. Não vão colocar um centavo a mais em mão de obra para coisa alguma. E a Positivo também não vai fazer porcaria nenhuma. Sempre existe a possibilidade de algum voluntário fazer o trabalho. Pode acontecer semana que vem, ou nunca... Então, larga de mão e tenta conseguir um hardware decente, nem que seja usado. Isso aí é lixo eletrônico.

Não. Antigamente, placas de vídeo muito velhas (anteriores a ~2015), sem VBIOS compatível, eram a causa provável. Só que são cacarecos defuntos a esta altura do campeonato e já apareceu relato similar até com vídeo integrado em placas-mãe recentes. Eu tendo a acreditar que é tudo BIOS bugado, mas sabe-se lá. A minha teoria é a seguinte: em todos os PCs de grife com Windows pré-instalado de fábrica, essa celeuma não acontece nunca. Então deve ser coisa do mercado de peças avulsas apenas, em que alguns BIOS são mal programados.

Sim, é uma alternativa. Só que a B450M Steel Legend é uma placa nova. Teria que funcionar, não fossem esses BIOS lamentáveis de certas marcas. CSM nem deveria mais existir e Secure Boot deveria ser habilitado por padrão. Infelizmente a situação é tão trágica que, no manual da placa em questão, consta o seguinte na descrição da opção "CSM", no menu "Boot -> CSM": Enable to launch the Compatibility Support Module. Please do not disable unless you’re running a WHCK test. Daí fica difícil.

Tire uma foto do menu "Security -> Secure Boot".

Restaurar as chaves, "Restore Factory Keys" ou algo assim.

Falando do Linux... Lembrando que isso afeta apenas arquiteturas 32-bit em que time_t seja 32-bit (a maioria). O grosso da solução é substituir time_t 32-bit por 64-bit. Requer no mínimo uma recompilação dos programas -- e possivelmente mudanças no código. No kernel, está encaminhado desde, mais ou menos, o 5.6 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22b17db4ea05561c7c8e4d770f10751e22e339f9). Faz anos que Arnd Bergmann enfrenta o problema. Os principais sistemas de arquivos também suportam datas posteriores (Btrfs, XFS, EXT4, ...). No espaço de usuário, a glibc, biblioteca C mais popular, manterá as interfaces antigas para programas que não possam ser recompilados/adaptados: https://sourceware.org/glibc/wiki/Y2038ProofnessDesign Podemos esperar que todos os componentes críticos sejam portados muito antes da fatídica data. No entanto, mesmo em arquiteturas 64-bit, há alguns lugares em que time_t continua sendo 32-bit: https://github.com/thkukuk/utmpx/blob/main/Y2038.md O pessoal da glibc simplesmente não vai consertar essas interfaces, pois são consideras obsoletas. Então, Thorsten Kukuk da SUSE tem trabalhado em substitutos. Não vai ser uma hecatombe, pois: 1) Arquiteturas 64-bit serão a esmagadora maioria em 2038 e os poucos pontos de fraqueza (como as interfaces citadas acima) terão sido resolvidos. 2) Arquiteturas 32-bit requererão mais trabalho. Os códigos importantes estarão preparados. Algum programa caduco que outro não será atualizado e vai ter problema em 2038.