OOT: sharing about my research about why stat and ls show difference used block count upon a file

[Mulyadi Santosa]

Hi Joao! :)

2011/7/2 João Eduardo Luís <jecluis at gmail.com>:
> Hello.
>
> Nice post. I had never noticed that. And I am able to reproduce the ls-stat behavior on a debian box with ext4 fs and no SELinux, or any other ACL's whatsoever.

OK, so far I can conclude it's not 100% reproducible on every
case...and it looks it is indeed due to enabled ACL and/or
SELinux...hmmmmmm


> You state:
>
>> But my friend pointed that stat was accouting extra blocks that might (I say "might" because my friend is not so sure) contain metadata such as SELinux and ACL.
>
> I am no ext3 expert, but I cannot wrap my head around the FS accounting for *metadata* blocks when stat is invoked. And I don't believe the ACLs would be kept within data blocks either, so this makes little sense to me.


I am also still digging a bit further about that. Spare time is my
only problem now plus my health. So, I am open for suggestion for
other people here. But still, thanks for sharing your opinions. It
means a lot for me (who is no expert in fs :D )

> In any case, after looking at ext3, I now believe the 'getattr' method in 'struct inode_operations' is left for the VFS to handle with its 'generic_fillattr()' method, and it pretty much copies everything relevant from the inode to the 'struct kstat'. Thing is, does the inode 'i_blocks' field keep track of both metadata and data blocks, or only data blocks? (I think only the latter makes any sense, but hey, that's just me).

Sssshhhh, I felt this will lead into another accounting journey, just
like when I wrote about /proc/meminfo...great :D

Wonder what tools could help me here.... cscope? watchpoints of gdb..... ufffff

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com