> fsck should drop in and remove the inode before mount. Or a journal > replay should. Because in this situation the filesystem can't be marked > clean (it can't be unmounted if it's dcache can't be purged and it can't > be purged when there are open files). > > So if orphaned inode is seen beyond fsck and/or journal replay, it's > a driver bug. I am having a problem with orphaned inodes also. I am not surprised that we have some sort of a file-system problem because we are using EXT3 and the normal mode of operation is to power-off vs. shutdown the system. The interesting / frustrating part is that fsck does not fix the problem! It identifies the problem, claims that it has been fixed and marks the partition as clean. However if you force a fsck after the partition has been *fixed* the same orphan inodes are found and repaired. Has anyone else seen this problem? Is there a way to repair orphaned inodes after they are created? Will the system just use the orphaned ones the next time it needs an inode? TIA -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
