On Tue, Nov 27, 2007 at 12:11:41PM +0900, [EMAIL PROTECTED] wrote: > Additionary, there is a limitation or specification in tmpfs. > It does not reclaim the inode number, and this behaviour MAY make aufs > to do the same behaviour too. In this case, the file size of xino grows. > Try 'df -i' and 'ls -i' for your tmpfs, and watch how inode-number will > be assigned and how the number of free inodes is decremented with your > test script.
Yes, I see. The inode numbers assigned to new files on tmpfs always grow. Discontiguously, too. > Specifying the total number of inode for tmpfs may be worth, but I am > afraid that you need to use other filesystem for your writable branch, Interesting. What other choice do I have if I'm using a typical writable-cow-on-readonly-squashfs sort of embedded setup? What about just using noxino? In what situations is xino necessary? What sort of programs would notice they were running on a noxino union? I'm aware of backup programs like amanda paying attention to inode numbers, but I don't know of anything else where it matters. btw, the total number of inodes for tmpfs appears to be unrelated to the numbers it assigns, so limiting the total won't help. thanks, Jason ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
