On Fri, 2003-05-23 at 09:55, Allen Curtis wrote: > > 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. As I understand it, the orphaned inodes should be easily cleaned up via either fsck or by mounting the FS. To restate your problem you are... fsck -f /dev/xxxx <get orphaned inode messages> fsck -f /dev/xxxx <still get orphaned inode messages> Try doing... mount /dev/xxxx umount /dev/xxxx fsck -f /dev/xxxx If you still get those errors, I would suggest posting your problem to an ext3 specific mailing list. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
