Zbr's days.
←April→
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
←2008→
Months
Jan Feb Mar
AprMay Jun
Jul Aug Sep
Oct Nov Dec

About TODO Blog RSS Old blog Projects Gallery Notes

Thu, 10 Apr 2008

Busy inodes after unmount. 

VFS: Busy inodes after unmount of pohmel. Self-destruct in 5 seconds.  Have a nice day...
After removing private cache of inodes I found, that objects, which were sent by the server and which were never attached to directory entry (dentry), will never be freed.
So, essentially this does not work with Linux VFS:
iget()/iget_locked()
...
umount
Inodes, created by iget()/iget_locked() will be placed into at least three different lists:
  • inode_in_use - global list of ever created inodes, which have i_count and i_nlink more than 0
  • s_inodes - per superblock list, which contains every inode, created for this superblock
  • inode_hashtable - hash table indexed by inode number. If you want to work with writeback, your inodes have to be there. Did not yet investigate why.
So, essentially all inodes, which you created, are accessible by VFS and will be checked during umount via generic_shutdown_super()->invalidate_inodes(), where system will notice that if inode in s_inodes list has non-zero reference counter (or course, otherwise it would be already freed by filesystem), then this inode can not be freed. Thus we have a leak.

Above lists can only be accessed under global inode lock, so it is not a good idea to destroy inodes traversing them in for example ->put_super() callback or in any other filessytem callback, so I had to add a list of all inodes into POHMELFS superblock. Ugly.

/devel/fs :: Link / Comments (0)

Please solve this captcha to be allowed to post (need to reload in a minute): 49 + 5

Comments are closed for this story.