Hello yam, "p. yam": > I have a question about the algorithm of recycling aufs inode number. > > 1. The outline of the problem: > The following command sequence, (a)..(d) , shows something strange. > > (a) cd /some-aufs-directory > (b) ls -id some-directory-which-inode-is-99 > ==> this shows inode number 99. > (c) rmdir some-directory-which-inode-is-99 > (d) ls -id other-directory-which-inode-is-unknown > ==> sometimes this shows inode number 99. > > But the inode number 99 should NOT exist, since it was 'rmdir'ed at (c).
If you had accessed other-directory-which-inode-is-unknown before removing some-directory-which-inode-is-99, the inode number of other-... would not become 99. Aufs has no its backend block device which means all aufs inode numbers are NOT assigned when you mount aufs. When you access a file, aufs finds that it exists and assigns an inode number for it. Your other-... in aufs didn't have its inode number and gets the number when you executes ls -id other-... If 99 was already assigned another existing file and aufs assigns 99 to unrelated file, then that was a problem. In your case, 99 is free now. No file has 99 as its inode number. So I don't think it a problem. But I can understand it looks strange, since other-... existed before removing some-... and you expect they already have uniq inode number for each. In aufs, the file which has never accessed doesn't have its inode number. J. R. Okajima ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
