On Monday 08 December 2008 16:38, Mike Snitzer wrote: > On Mon, Dec 8, 2008 at 5:20 PM, Daniel Phillips <[EMAIL PROTECTED]> wrote: > > On Monday 08 December 2008 13:02, Mike Snitzer wrote: > >> So my question is, how might tux3 be trained to _not_ cleanup orphaned > >> inodes on re-mount like conventional Linux fileystems? Could a > >> re-mount filter be added that would trap and then somehow reschedule > >> tux3's deferred delete of orphan inodes? This would leave a window of > >> time for an exposed hook to be called (by an upper layer) to > >> reconstitute a reference on each orphaned inode that is still open. > > > > Something like the NFS silly rename problem. There, the client avoids > > closing a file by renaming it instead, which creates a cleanup problem. > > Something more elegant ought to be possible. > > > > If the dirent is gone, leaving an orphaned inode, and the filesystem > > has been convinced not to delete the orphan on restart, how would you > > re-open the file? Open by inode number from within kernel? > > Well, in a distributed filesystem the server-side may not even have > the notion of open or closed; the client is concerned with such > details. > > But yes, some mechanism to read the orphaned inode off the disk into > memory. E.g. iget5_locked, linux gives you enough rope to defeat > n_link==0, combined with a call to read_inode() (ext3_read_inode() > became ext3_iget()). Unfortunately to read orphaned inodes with ext3 > that requires clearing the EXT3_ORPHAN_FS flag in the super_block's > s_mount_state. > > It is all quite ugly; and maybe a corner-case that tux3 doesn't > need/want to worry about?
Would a mount option to move orphans into lost+found on remount do the trick? Regards, Daniel _______________________________________________ Tux3 mailing list [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
