My English and brain are broken, sorry. sf...@users.sourceforge.net: > Here is my guess. > - syslogd opens these log files for write. > - in the beginning, files exist on the lower ext3 only. no on the upper > tmpfs. > - aufs opens files on the lower ext3. > - when syslogd writes to them first time, aufs copies-up them to the > upper tmpfs and closes the one on the lower ext3. > while the file object (a kernel object in memory) for ext3 is > released, the inode object for ext3 is still referenced. It means the > ext3 inode still exist on memory. > - rsync copies the file. the target file is removed ext3 doesn't release > the resources for the file since the inode is still referenced and > alive.
rsync copies the file. the target file is removed but ext3 doesn't release the resources for the file since the inode is still referenced and alive. > And these removed but still alive files may be related to the ext3's > orphaned inode list. These inodes will be freed and ext3 resources for > them will be freed too when you unmount ext3. But when you unmount it, > ext3 is set to already, right? ext3 is already set to readonly, right? > So ext3 could not write "this inode is free now" mark to the backend > device, I guess. > > If this option is correct, it is worth to try remounting ext3 writable > in your shutdown script. But it is just my guess. If this guess is correct, ... J. R. Okajima ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev
