filefrag fibmap retornando deslocamento físico errado para o FAT

3

Eu estou tentando obter o mapa de espaço vazio em qualquer partição de maneira agnóstica do sistema de arquivos. Para fazer isso eu crio um arquivo que usa todo o espaço vazio, então use o comando 'filefrag -e' (e2fsprogs v1.42.9) para criar um mapa do espaço (no Ubuntu 14.04 Trusty, testado com kernels 3.16.0- 67 e 4.1.20-040120, dosfstools v3.0.26-1).

Isso funciona para a maioria dos sistemas de arquivos, mas para sistemas de arquivos FAT, especificamente, estou obtendo offsets físicos além do tamanho da partição. Observe que o problema foi alterado, consulte a edição abaixo.

$ dd if=/dev/zero of=temp.img bs=512 count=2048000
$ sudo losetup /dev/loop1 ./temp.img
$ sudo parted /dev/loop1 mklabel msdos
$ sudo parted /dev/loop1 mkpart primary fat32 2048s 1026047s
$ sudo blockdev --rereadpt /dev/loop1
$ sudo mkfs -t vfat /dev/loop1p1
$ sudo mount /dev/loop1p1 ./mnt
$ sudo cp somefile1 ./mnt
$ sudo cp somefile2 ./mnt
$ df -B 512 ./mnt
Filesystem     512B-blocks  Used Available Use% Mounted on
/dev/loop1p1       1023440 21232   1002208   3% ./mnt
$ sudo dd if=/dev/zero of=./mnt/emptyspace.zeros bs=512 count=1002208
$ df -B 512 ./mnt
Filesystem     512B-blocks    Used Available Use% Mounted on
/dev/loop1p1       1023440 1023440         0 100% ./mnt
$ sudo filefrag -b512 -e ./mnt/emptyspace.zeros 
Filesystem type is: 4d44
File size of ./mnt/emptyspace.zeros is 513130496 (1002208 blocks of 512 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0.. 1002207:     348688..   1350895: 1002208:    1350880: merged,eof
./mnt/emptyspace.zeros: 1 extent found
$ cat /proc/mounts
/dev/loop1p1 .../mnt vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,
  iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
$ sudo umount /dev/loop1p1
$ sudo fsck /dev/loop1p1
fsck from util-linux 2.20.1
fsck.fat 3.0.26 (2014-03-07)
/dev/loop1p1: 4 files, 63965/63965 clusters
$ echo $?
0

(filefrag retorna offsets físicos em relação ao início da partição)

$ cat /sys/class/block/loop1p1/start 
2048
$ cat /sys/class/block/loop1p1/size
1024000

(o tamanho e o tamanho do sysfs estão em setores de 512 bytes)

Claramente 1350895 é maior que 1024000. Isso é um bug na implementação vfat / fat do FIBMAP ioctl do Linux ou há outra razão para isso?

Noto que EmmaV envia um comentário em alusão a esse problema em esta questão mas não houve uma resposta definitiva.

Também entrei em contato com Theodore Ts'o (autor do arquivo filefrag) e ele não indicou um problema conhecido com o filefrag.

EDITAR: Além disso, descobri que o problema acima é causado por um bug no e2fsprogs v1.42.9. Uma correção para isso é disponível aqui , que é incluído pela primeira vez em e2fsprogs v1.42.12. Eu atualizei e testei e a saída é muito diferente.

No entanto, ainda estou tendo problemas com sistemas de arquivos FAT. O deslocamento está agora dentro da partição, pelo menos, mas a comparação do conteúdo de um arquivo com os blocos retornados pelo filefrag gera uma diferença. Eu escrevi um script python aqui para teste. Ficaria muito grato por qualquer feedback e sugestões sobre qual é o problema.

Pontos de bônus vão para a pessoa que pode me dizer o problema com o mkfs para btrfs! :)

    
por racitup 27.03.2016 / 22:55

1 resposta

0

Eu estive em contato com OGAWA Hirofumi e Theodore Ts'o e testei vários kernels e tags e2fsprogs. O problema restante é corrigido no e2fsprogs v1.43-WIP a partir de 2015. Acredito que este commit resolveu o problema.

O histórico completo de testes e o script de teste podem ser encontrados aqui .

A moral da história: não se incomode em usar o filefrag para sistemas de arquivos FAT, a menos que esteja escrito 1.43-WIP e 2015+ na parte inferior da página man.

Devo mencionar também que o hdparm --fibmap também possui uma implementação com bugs na v9.43. Você precisará de pelo menos v9.45, mas eu não validei completamente o hdparm como filefrag.

    
por 02.04.2016 / 03:52

Tags