Por que o diretório / lost + encontrou 16K em vez de 4K bytes?

Eu estava na direção da raiz /, e fiz ls -lahpor qualquer motivo e observei os tamanhos das pastas. Percebi que a pasta lost+foundtem um tamanho de 16K, enquanto todos os outros diretórios têm um tamanho de 4K. /dev,, /proce também /syssão de tamanhos diferentes, mas lost+foundera o que eu estava inicialmente curioso.

As pessoas têm apontado que /devé porque ele é um sistema de arquivos diferente, e que /proce /syssão sistemas de arquivos virtuais para que eles não seguem as mesmas regras como um normal.

Alguém tem uma explicação para isso (o lost+founddiretório)? De um rápido Google, não consegui encontrar uma resposta

-rw-r--r--  1 root root  152 Jul  2 11:47 extlinux.conf
drwxr-xr-x  3 root root 4.0K Nov  7 01:51 home
lrwxrwxrwx  1 root root   30 Jul  2 11:47 initrd.img -> /boot/initrd.img-3.2.0-4-amd64
-r--r--r--  1 root root  32K Jul  2 11:47 ldlinux.sys
drwxr-xr-x 12 root root 4.0K Jul  2 11:46 lib
drwxr-xr-x  2 root root 4.0K Nov  7 01:43 lib64
drwx------  2 root root  16K Jul  2 11:44 lost+found
drwxr-xr-x  2 root root 4.0K Jul  2 11:46 media
drwxr-xr-x  2 root root 4.0K Dec 24  2014 mnt
drwxr-xr-x  4 root root 4.0K Nov 14 22:00 opt
dr-xr-xr-x 85 root root    0 Nov  9 19:51 proc
drwx------  3 root root 4.0K Nov 15 21:01 root
drwxr-xr-x 15 root root  480 Nov 15 23:26 run
drwxr-xr-x  2 root root 4.0K Nov  7 01:43 sbin

Edit: I see the question O que significa tamanho de um diretório na saída do comando 'ls -l'? que tipo de resposta à pergunta, mas todos os novos diretórios que faço são de 4,0K e, lost+foundaté onde eu sei , nunca tive nenhuma informação que justificasse um tamanho maior (esta é uma instalação relativamente nova, sem a necessidade de desligamentos). Além disso, para esclarecimento, o tipo de sistema de arquivos é ext3.

Editar 2: esses arquivos podem ser mais úteis para pessoas que realmente podem interpretá-los, mas ainda não explicam por que / run é diferente, mas alguém sugeriu que isso ocorre porque ele está montado (verificado com df -h). Também é criado pelo mklost+foundcomando, mas quando esse comando é executado, o tamanho do diretório é mostrado como 49K (12 blocos) em vez de 16K (4 blocos). O arquivo mke2fs.c explica o arquivo 16K com a linha if ((lpf_size += fs->blocksize) >= 16*1024), mas não o 49k.

linux filesystems lost-found

— cutrightjm
fonte

É mais simples para o fsck criar apenas um diretório perdido + encontrado com mais espaço reservado para os arquivos encontrados do que expandi-lo se / quando necessário. Com alguns tipos de corrupção do fs, talvez nem seja possível ou seguro expandir o diretório perdido + encontrado enquanto o fsck está corrigindo erros.

— cas

@cas então 16K parece ser de 4 blocos, onde um diretório padrão é de 1 bloco. Por que / dev e / proc ser menor do que isso .. parece que seria apenas tornar as coisas mais difíceis para o sistema de arquivos

— cutrightjm

centenas ou milhares de arquivos pequenos. O tamanho do diretório está relacionado ao número de entradas (arquivos) nele, não ao tamanho dos arquivos. não consigo ver por que você faria isso.

— cas

a menos que você tenha um uso específico para essas informações (por exemplo, você é um hacker de driver de fs ou hacker de kernel), eu apenas o arquivo na cesta "coisas vagamente interessantes que não importam".

— cas

Eu gosto de raciocínio. Muitas vezes, você também notaria que se um diretório for usado e os arquivos forem apagados, o tamanho não diminui.

— Rui F Ribeiro

@cas estava correto ao supor que "É mais simples para o fsck criar um diretório perdido + encontrado com mais espaço reservado para os arquivos encontrados do que expandi-lo se / quando necessário. Com alguns tipos de corrupção do fs, talvez nem seja possível ou é seguro expandir o diretório perdido + encontrado enquanto o fsck está corrigindo erros ".

Não sei por que não fiz isso antes, mas se você consultar a mklost+foundpágina de manual, ela fornecerá essas informações:

O mklost + found pré-aloca blocos de disco para o diretório lost + found, de modo que quando o e2fsck (8) está sendo executado para recuperar um sistema de arquivos, ele não precisa alocar blocos no sistema de arquivos para armazenar um grande número de arquivos não vinculados. Isso garante que o e2fsck não precisará alocar blocos de dados no sistema de arquivos durante a recuperação.

A resposta mais profunda para a pergunta específica, por que o tamanho do arquivo é 49.152 KB (ou 49 MiB ou 12 setores), está em algum lugar nos arquivos abaixo. É por isso que eu estava tão curioso, mas ainda não o descobri (não sei ler muito bem C). Se alguém tiver tempo livre, me conhecer e puder explicar o porquê, aceitarei sua resposta sobre esta:

— cutrightjm
fonte