Por que o inode number é zero para o mecanismo writeback no kernel do linux

Question

Estou pesquisando o kernel do Linux. No momento, apenas para a v3.10.61, é apenas uma prova de conceito.

Eu preciso passar algumas dicas para o hardware sobre qual tipo de dados, em particular, a operação WRITE \ READ. Por exemplo. leia bitmap de inodes ou escreva bloco de diário ou escreva dados de usuário ou qualquer outra coisa ...

Estou assumindo que no nível do driver eu posso alcançar bio struct de request_queue struct .

1. Eu criei o FS com este comando: mkfs.ext4 -b 4096 -E lazy_itable_init=0,lazy_journal_init=0 -m 0 /dev/vda
2. Eu montei usando este comando: mount -o rw,nosuid,nodev,discard,noauto_da_alloc,data=ordered /dev/vda /mnt
3. Adicionou o ponto de interrupção em virtio_blk.c:377 e pulará gravações relacionadas ao diário
4. Execute este comando dd: dd if=/dev/urandom of=/mnt/foo2 bs=764 count=34
5. Aguarde o hit do ponto de interrupção e analisaremos o backtrace no subsistema de write-back.

Aqui está o backtrace:

#0  virtblk_request (q=0x87ab8000) at drivers/block/virtio_blk.c:377
#1  0x801c0b4c in __blk_run_queue_uncond (q=<optimized out>) at block/blk-core.c:312
#2  __blk_run_queue (q=0x87ab8000) at block/blk-core.c:329
#3  0x801c0c94 in queue_unplugged (q=0x87ab8000, depth=<optimized out>, from_schedule=<optimized out>) at block/blk-core.c:2920
#4  0x801c3a98 in blk_flush_plug_list (plug=<optimized out>, from_schedule=false) at block/blk-core.c:3030
#5  0x801c3d9c in blk_finish_plug (plug=0x8785fd8c) at block/blk-core.c:3037
#6  0x80091644 in generic_writepages (mapping=<optimized out>, wbc=0x8785fde0) at mm/page-writeback.c:1910
#7  0x80092a88 in do_writepages (mapping=<optimized out>, wbc=<optimized out>) at mm/page-writeback.c:1923
#8  0x800e7084 in __writeback_single_inode (inode=0x8740c290, wbc=0x8785fde0) at fs/fs-writeback.c:454
#9  0x800e7360 in writeback_sb_inodes (sb=0x87811000, wb=0x87ab81b0, work=0x8785fea4) at fs/fs-writeback.c:678
#10 0x800e757c in __writeback_inodes_wb (wb=0x1 <__vectors_start>, work=0x3ff) at fs/fs-writeback.c:723
#11 0x800e7760 in wb_writeback (wb=0x87ab81b0, work=0x8785fea4) at fs/fs-writeback.c:854
#12 0x800e838c in wb_check_old_data_flush (wb=<optimized out>) at fs/fs-writeback.c:969
#13 wb_do_writeback (wb=0x87ab81b0, force_wait=0) at fs/fs-writeback.c:1010
#14 0x800e848c in bdi_writeback_workfn (work=0x87ab81bc) at fs/fs-writeback.c:1040
#15 0x80039d34 in process_one_work (worker=0x87816180, work=0x87ab81bc) at kernel/workqueue.c:2189
#16 0x8003a40c in worker_thread (__worker=0x1 <__vectors_start>) at kernel/workqueue.c:2313
#17 0x8003f714 in kthread (_create=0x87845e20) at kernel/kthread.c:200
#18 0x8000dfb8 in ret_from_fork () at arch/arm/kernel/entry-common.S:91

Ok, aqui vamos nós ... No quadro 8, não otimizamos a variável inode para inspeção:

p (*inode)->i_ino
$7 = 0

Alguém pode me explicar o que é este inode? Onde posso encontrar informações sobre este tipo de inodes? E como posso rastrear o número de inode para as ofertas de write-back?

    

Answer 1

Isenção de responsabilidade: Eu não tentei nenhuma dessas funções e estou trabalhando na documentação e nos comentários. Minhas observações podem estar incorretas!

A única função que posso ver que usa o valor i_ino em fs/writeback.c é a função interna block_dump___mark_inode_dirty , que marca um inode como sujo se foi hash (e ainda não está marcado) e define um timestamp (para futuras operações de write-back.) A lista atual de inodes a serem gravados parece estar disponível como uma lista ( struct bdi_writeback *wb ) dada a wb_writeback() .

Como você usou data=ordered em suas opções de montagem, não acredito que ocorram writebacks de dados, portanto nenhum inodes deve ser considerado "sujo". De acordo com a documentação do ext4 :

data=ordered (*)

All data are forced directly out to the main file system prior to its metadata being committed to the journal.

Mais tarde, uma descrição de como o writeback funciona no ext4:

Data Mode

• writeback mode

In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance.

• ordered mode

In data=ordered mode, ext4 only officially journals metadata, but it logically groups metadata information related to data changes with the data blocks into a single unit called a transaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode.

Se você deseja rastrear eventos em uma partição ext4, talvez esteja interessado em ver como a interface ext4-JBD2 funciona em fs/ext4/ext4_jbd2.c e as interfaces de rastreamento disponíveis em include/trace/events/ext4.h .