Cyanrigger: > Here is a listing of the files that are moved with the rsync script. > When I compare the inode numbers from that files with the ones, fsck > complains about I found out that they're all log-files. > (please see the comments in the pastebin link) > > http://pastebin.com/uiD6PBTH > > I tried this test again after a reboot, and after killing the "syslogd" > and "klogd" processes and the errors are gone! It's reproducible.
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. 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? 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. 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
