Perguntas[filesystems](unix)

Meu problema é decodificar a saída do comando file -s /dev/sdXno meu sistema (onde /dev/sdXestá o arquivo de dispositivo associado a uma chave USB).
Abaixo, mostrarei a saída do comando file -s /dev/sdXem que o arquivo de dispositivo /dev/sda1é uma partição formatada com um FAT32sistema de arquivos, enquanto o dispositivo /dev/sdbé uma partição formatada com um NTFSsistema de arquivos.

Saída de filecomando para um FAT32sistema de arquivos

No caso do FAT32sistema de arquivos, a saída do filecomando é:

> file -s /dev/sda1
/dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 31, hidden sectors 2048, sectors 1966080 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1920, reserved 0x1, serial number 0x4ba3ff5b, unlabeled

Na saída está presente a informação , FAT (32 bit), sectors/FAT 1920,que poderia ser suficiente para dizer que o tipo de sistema de arquivos é FAT32, mas no próximo parágrafo mostrarei que a string FATtambém está presente na saída do filecomando no caso de um NTFSsistema de arquivos.

Saída de filecomando para um NTFSsistema de arquivos

No caso de um NTFSsistema de arquivos, a saída do filecomando é:

> file -s /dev/sdb 
/dev/sdb: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS    ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, dos < 4.0 BootSector (0x0), FAT (1Y bit by descriptor); NTFS, sectors/track 63, physical drive 0x80, sectors 15654911, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 030fcd5a9fcd56a1c; contains bootstrap BOOTMGR

Nesta saída está presente a informação, ; NTFS,mas também está presente a string FAT.

A questão

A partir das saídas anteriores do file -scomando, como determinar o sistema de arquivos das duas partições com certeza?

EDITAR
Adiciono a saída do file -scomando para uma exfatpartição e para uma ext4partição.

Saída de fileparaexfat

> file -s /dev/sdf
/dev/sdf: DOS/MBR boot sector

Neste caso exfatnão está presente na saída.

Saída de fileparaext4

file -s /dev/sdb1
/dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=38bc3d5b-381e-4f19-8640-c77d9483882b (needs journal recovery) (extents) (64bit) (large files) (huge files)

Neste caso está presente a informação ext4 filesystem data,.

Nestes 4 exemplos (FAT32, NTFS, EXFAT, EXT4), a saída do filecomando parece muito diferente para diferentes tipos de sistema de arquivos, por isso é difícil encontrar uma regra simples para decidir o tipo de sistema de arquivos por essa saída.

Preciso montar um pendrive antigo formatado com o sistema de arquivos FAT. A montagem deve ser executada automaticamente por uma udevregra que execute um script bash.

Quando a chave USB é inserida na porta USB, o script executa o comando:

blkid -o udev /dev/sda1 

onde /dev/sda1está a partição presente dentro do USB e formatada com o sistema de arquivos FAT32. A saída do comando anterior para o pendrive está vazia .

A saída do mesmo comando ( blkid) para outras chaves USB contém a udevvariável ID_FS_TYPE; os valores possíveis ID_FS_TYPEsão: vfat, ntfs, exfat.

Diferentes opções de mountcomando se o sistema de arquivos forvfat

Se o valor da variável ID_FS_TYPEfor vfato script deve executar o seguinte mountcomando:

> mount -o rw,relatime,users,gid=100,umask=000,shortname=mixed,utf8=1,flush /dev/sda1 /mount/point

Enquanto que se o sistema de arquivos não estiver, vfatas opções para o mountcomando podem ser as seguintes:

mount -o rw,relatime /dev/sda1 /mount/point

Com a chave USB específica (1 GB e muito antiga), o script não consegue saber qual é o tipo de sistema de arquivos, vfatentão ele executa o segundo mountcomando; o resultado é que as permissões para o diretório do ponto de montagem (chamado /media/sda1) são:

> ls -l /media/    
total 16
drwxr-xr-x 3 root root 16384 Jan  1  1970 sda1

enquanto eu preciso:

# ls -l /media/    
total 16
drwxrwxrwx 3 root root 16384 Jan  1  1970 sda1

Preciso dessas permissões porque todos os usuários devem poder escrever no USB e não apenas o proprietário (que é rooto meu contexto).

Encontre o tipo de sistema de arquivo por outros comandos

Este link dá outras dicas para descobrir o tipo de sistema de arquivos deste pendrive específico. Então, tentei outros comandos:

• lsblk -n -o FSTYPE /dev/sda1: também neste caso, para minha chave USB específica, a saída do comando está vazia
• a saída do comando file -sL /dev/sda1é muito longa; mostro esta saída abaixo:

> file -sL /dev/sda1
/dev/sda1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "MSDOS5.0", sectors/cluster 32, reserved sectors 8, root entries 512, Media descriptor 0xf8, sectors/FAT 240, sectors/track 63, heads 255, hidden sectors 2048, sectors 1966080 (volumes > 32 MB), reserved 0x1, serial number 0xa4906b9d, unlabeled, FAT (16 bit)

Nesta saída, a informação está presente FAT (16 bit), mas não fica claro se o sistema de arquivos da partição do pendrive está formatado vfat. Se eu executar o comando anterior file -sLem um pendrive formatado com o sistema de arquivos NTFS, a saída do comando será:

> file -sL /dev/sda
/dev/sda: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS    ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, dos < 4.0 BootSector (0x0), FAT (1Y bit by descriptor); NTFS, sectors/track 63, physical drive 0x80, sectors 15654911, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 030fcd5a9fcd56a1c; contains bootstrap BOOTMGR

Nesta saída está presente a string NTFS, mas também está presente a string FAT, então com esta saída não é fácil estabelecer se o sistema de arquivos é vfate não ntfs.

A questão

Existe algum comando além dos anteriores que possa fornecer o sistema de arquivos de uma partição antes de montá-la?

Estou tentando entender se é possível mapear dois usuários de um namespace de usuário para dois usuários diferentes no host.

O objetivo é replicar as mesmas permissões que tenho no meu host dentro de uma rootfs(base Ubuntu, porque estou tentando construir um contêiner do zero).

Por exemplo:

• Tudo abaixo /deve pertencer a root.
• /home/userdeve pertencer ao regular user.

Para conseguir isso, pensei em usar o mapeamento de UID em um namespace de usuário, algo como:

UID in user namespace      ---> UID on host
      1000 (admin)         ->       0 (root)
      1001 (bob)           ->    1001 (bob)

Esse tipo de mapeamento é mesmo possível?

Aqui está o que eu já tentei:

• Executando echo -e "1000 0 1\n1001 1001 1" > /proc/[PID]/uid_mappara definir o mapeamento, mas recebo um erro.
• Tentando modificar manualmente /proc/[PID]/uid_mappara newuidmapcada usuário.

No entanto, nunca consegui mapear mais de um usuário e não consigo mapear o UID 0 (root) de jeito nenhum.

Atualizar:

Li as páginas de manual e segui as restrições mencionadas ali, mas ainda estou recebendo mensagens de erro.

Por exemplo:

# terminal 1

unshare --user bash
echo $$ # 11591

# terminal 2 as user 'alex' (uid = 1000)

newuidmap 11591 0 0 1
# newuidmap: uid range [0-1) -> [0-1) not allowed

newuidmap 11591 1001 1001 1
# newuidmap: uid range [1001-1002) -> [1001-1002) not allowed

Esses comandos falham, mesmo quando executados com sudo.

Também tentei mapear os subuids que declarei, mas ainda não funciona:

cat /etc/subuid

alex:100000:65536
root:200000:65536
self:300000:65536

cat /etc/subgid

alex:100000:65536
root:200000:65536
self:300000:65536

Para habilitar a montagem de uma chave USB formatada com sistema de arquivos, ntfscriei o seguinte fragment.cfgarquivo:

CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

e compilei o kernel com o comando:

bitbake -C compile virtual/kernel

Com essa modificação na configuração do kernel minha distribuição consegue executar a montagem de um ntfsUSB pelo comando:

> mount /dev/sda /media/sda

onde /dev/sdaestá o dispositivo associado à chave USB e /media/sdaé o ponto de montagem.

O sistema de arquivos é montado, mas somente leitura. Isso é mostrado pelo comando a seguir:

# mount | grep media
/dev/sda on /media/sda type ntfs (ro,relatime,uid=0,gid=0,fmask=0177,dmask=077,nls=iso8859-1,errors=continue,mft_zone_multiplier=1)

No arquivo de fragmento que configurei CONFIG_NTFS_RW=y, então por que o ntfssistema de arquivos de uma chave USB é montado somente leitura?

EDITAR

Se eu executar o comando dmesgobtenho a seguinte mensagem:

> dmesg
...
(device sda): load_system_files(): Volume is dirty.  Mounting read-only.  Run chkdsk and mount in Windows.

Eu segui as informações escritas na mensagem anterior:

• Eu inseri o USB em um sistema Windows
• O sistema Windows executou um scanfix do USB

Depois disso executei corretamente a montagem R/W do USB no meu sistema Linux:

> mount -t ntfs /dev/sda /media/sda
> mount | grep media
/dev/sda on /media/sda type ntfs (rw,relatime,uid=0,gid=0,fmask=0177,dmask=077,nls=iso8859-1,errors=continue,mft_zone_multiplier=1)

Neste ponto, se eu tentar escrever no USB, recebo o seguinte erro:

> touch /media/sda/write_ntfs.txt
touch: cannot touch '/media/sda/write_ntfs.txt': Permission denied

O mesmo se eu tentar alterar a permissão de um arquivo presente no USB:

> chmod 777 /media/sda/filename.csv
chmod: changing permissions of '/media/sda/filename.csv': Operation not supported

Então, apesar da saída do comando mount, parece que a montagem do USB ainda é somente leitura!

Estou pensando em usar btrfs para um volume de dados com muitos arquivos pequenos. Não está claro o que a documentação afirma sobre o tamanho mínimo de bloco possível.

Parece que eles e nós estamos em extremos muito diferentes da realidade. As ideias deles sobre o tamanho do bloco são aumentar o tamanho do bloco, a minha é diminuí-lo. Eles querem desperdiçar espaço em disco, eu quero poupá-lo. Também quero diminuir as operações de descarte-reescrita desnecessárias em volumes SSD.

Eles parecem estar indo tão longe que a documentação não é clara sobre o tamanho mínimo do cluster btrfs.

O que é? 4k? 16k? 64k?

Posso ter, por exemplo, blocos de 512 bytes?

Tenho um HDD externo (não ssd) que informa:

Sector Sizes:     512 bytes logical, 4096 bytes physical

Devo usar --sector-size 512ou --sector-size 4096com cryptosetup LuksFormat? Usando parâmetros padrão (não tenho certeza se ele tenta detectar automaticamente ou usar 512 sempre) acabou com 512.

Se for importante, a configuração será[disk]->[gpt]->[physical partition]->[LUKSv2]->[btrfs]

Fui em frente e usei ambas as maneiras de coletar benchmarks:

512

# sysbench fileio prepare
2147483648 bytes written in 34.28 seconds (59.75 MiB/sec).

# sysbench fileio --file-test-mode=rndrw run
Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      14.42
    writes/s:                     9.62
    fsyncs/s:                     31.25

Throughput:
    read, MiB/s:                  0.23
    written, MiB/s:               0.15

General statistics:
    total time:                          12.4778s
    total number of events:              562

Latency (ms):
         min:                                    0.00
         avg:                                   17.84
         max:                                  365.73
         95th percentile:                       84.47
         sum:                                10024.98

Threads fairness:
    events (avg/stddev):           562.0000/0.00
    execution time (avg/stddev):   10.0250/0.00


# sysbench fileio --file-test-mode=seqrewr run
Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential rewrite test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      0.00
    writes/s:                     815.93
    fsyncs/s:                     1045.19

Throughput:
    read, MiB/s:                  0.00
    written, MiB/s:               12.75

General statistics:
    total time:                          10.0488s
    total number of events:              18576

Latency (ms):
         min:                                    0.00
         avg:                                    0.54
         max:                                  433.66
         95th percentile:                        0.02
         sum:                                 9996.57

Threads fairness:
    events (avg/stddev):           18576.0000/0.00
    execution time (avg/stddev):   9.9966/0.00

##4096

# sysbench fileio prepare
2147483648 bytes written in 28.85 seconds (70.99 MiB/sec).


# sysbench --test=fileio --file-test-mode=rndrw run
File operations:
    reads/s:                      26.17
    writes/s:                     17.45
    fsyncs/s:                     58.35

Throughput:
    read, MiB/s:                  0.41
    written, MiB/s:               0.27

General statistics:
    total time:                          11.4636s
    total number of events:              1041

Latency (ms):
         min:                                    0.00
         avg:                                    9.63
         max:                                  370.49
         95th percentile:                       44.98
         sum:                                10021.97

Threads fairness:
    events (avg/stddev):           1041.0000/0.00
    execution time (avg/stddev):   10.0220/0.00



# sysbench fileio --file-test-mode=seqrewr run
File operations:
    reads/s:                      0.00
    writes/s:                     1229.02
    fsyncs/s:                     1574.44

Throughput:
    read, MiB/s:                  0.00
    written, MiB/s:               19.20

General statistics:
    total time:                          10.0071s
    total number of events:              27929

Latency (ms):
         min:                                    0.00
         avg:                                    0.36
         max:                                  471.49
         95th percentile:                        0.02
         sum:                                 9997.75

Threads fairness:
    events (avg/stddev):           27929.0000/0.00
    execution time (avg/stddev):   9.9978/0.00

Para arquivos artificiais pequenos, 4K parece ser duas vezes mais rápido para leituras e 0,25 mais rápido para gravações.

Outra edição. Fiz o mesmo teste, mas copiando 110G de um pacote de arquivos variando de 2,5Mb (95%tile) a 300Mb.

Tanto a unidade formatada em 512 quanto a formatada em 4096 levou 20m30s +-4s

Sei que os arquivos acessados ​​recentemente são armazenados em cache na RAM, mas há um cache para comandos frequentes?

Por exemplo, se eu executar cat file.txtvárias vezes, file.txtele será armazenado em cache após o primeiro comando.

1. Mas se eu executar ps auxvárias vezes, a saída do primeiro comando será armazenada em cache em algum lugar?
2. Cada aplicativo tem seu próprio cache para comandos frequentes; por exemplo git log?

Depois de ler esta pergunta relacionada , acho que o termo correto para isso é memorização .

Ao criar um disco USB de instalação, cometi o erro trivial de indicar o dispositivo errado e acabei sobrescrevendo as poucas centenas de megabytes iniciais de um disco de 230 GB.

Os dados não eram extremamente importantes, mas eu ainda gostaria de recuperar o que eu puder. A primeira tentativa, óbvia, foi photorec, que encontrou algumas coisas. Mas então, eu esperava poder "consertar" o que sobrou do sistema de arquivos (afinal, eu sobrescrevi menos de 0,5%).

Então eu tentei executar e2fsckcom várias combinações de parâmetros, incluindo o uso de um superbloco de backup (de forma análoga ao que é sugerido em uma resposta a uma pergunta relacionada ), e acabei com um monte de pastas em "lost+found" - justo. O problema é que algumas dessas pastas ainda dão erros como

ls: cannot access 'lost+found/#26128': Structure needs cleaning

... mas se eu executar novamente e2fsck -f(como sugerido em outras respostas ), não recebo nada de estranho

e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
EData: 191504/15269888 files (0.1% non-contiguous), 48227460/61049344 blocks

... e, a propósito, isso leva apenas alguns segundos, então está claro que não é realmente verificar todo o conteúdo do disco. Tentei verificar outras opções e, por exemplo, tentei -E discard, mas nada mudou: a verificação ainda é muito rápida, e algumas pastas internas lost+foundainda dão os mesmos erros.

Como posso corrigir os erros com essas pastas que dizem "Estrutura precisa de limpeza"?

Observe que o dispositivo está funcionando perfeitamente do ponto de vista de hardware.

Tenho este arquivo no disco:

$ ls -lh /path/to/some.mkv
-rwxr-xr-x 1 enrico enrico 7.4G Dec 17 18:54 /path/to/some.mkv

então é menos de 8 gigabytes, mas quando tento copiá-lo para um pen drive de 30 GiB, recebo este erro:

cp: error writing '/path/to/some.mkv': File too large

Aqui está o caminho:

$ sudo fdisk -l | tail -n 16

Disk /dev/sdc: 29.3 GiB, 31457280000 bytes, 61440000 sectors
Disk model: USB DISK        
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6f20736b

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdc1        778135908 1919645538 1141509631 544.3G 72 unknown
/dev/sdc2        168689522 2104717761 1936028240 923.2G 65 Novell Netware 386
/dev/sdc3       1869881465 3805909656 1936028192 923.2G 79 unknown
/dev/sdc4       2885681152 2885736650      55499  27.1M  d unknown

Partition table entries are not in disk order.
$ sudo mount /dev/sdc /mnt/foo
$ cd /mnt/foo
$ df . -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc         30G   16K   30G   1% /mnt/foo

Sou novato em Linux.

Estava lendo sobre o sistema de arquivos Linux e me deparei com os diretórios /mnte /media. AFAIK, ambos são usados ​​para montagem, e ouvi dizer /mediaque era o "novo" e era onde todos os dispositivos hot-swappable (por exemplo, pendrives USB) ficavam. Então, decidi experimentar...

Conectei meu pendrive, executei ls /mediae descobri que o Linux tinha criado um diretório com o nome do meu nome de usuário! Que fofo. Então executei ls /media/foo(com foo sendo meu nome de usuário) e encontrei o nome do meu pendrive lá. 'SanDisk 12.8.0 amd64 n'. Não faço ideia do que isso significa.

Por curiosidade, decidi ls /mnt, mas não encontrei nada!

Então... /mntpara que serve mesmo?