> Al Viro wrote: > >Define orphan. It might very well be still opened after the only link > >to it had been removed and you still will get IO on it. > > Well, in the mail I called files like open/unlink the last link/do some I/O > orphans. Let me shortly describe the problem I'm trying to solve. > > In our FS when we're in ->unlink() and i_nlink becomes 0, we have to record > this inode in the table of orphans, and remove it from there in > ->delete_inode(). This is needed to be able to dispose of orphans in case > of an unclean reboot on the next mount. AFAIK, ext3 has something similar. > I just figured that this could be optimized - in most cases > ->delete_inode() is called right after ->unlink(), and I wanted to avoid > putting the inode to the orphan table in those cases. Yes, ext3 has something similar. But actually ext3 would have to insert inode in the orphan list anyway - in delete_inode we do truncate and for it we also insert the inode into the orphan list because truncate can be too large to fit into a single transaction.
> I.e., if one just does "unlink file", then it is not going to be an orphan. > And most cases are like this. It is rather rare to open a file, unlink it, > and keep utilizing it. > > So my question was - while I'm in ->unlink(), how do I figure out that this > is not an orphan. So I was thinking about > > if (atomic_read(&inode->i_count) == 2) > > then this is not an orphan and ->delete_inode() will be called straight > away (i_nlink is assumed to be 0). > > But I've now also figured that ->unlink() may race with write-back, and > there might be a write-back I/O between ->unlink() (and during it) and > ->delete_inode(), even though the user-space does not have the file in > question opened. > > So, at the moment, AFAIU > > if (atomic_read(&inode->i_count) == 2 && !(inode->i_state & I_DIRTY)) > > then there won't be any I/O on the inode between ->unlink() and > ->delete_inode i_nlink is assumed to be 0). Is that right, safe and > acceptable to use such checks in ->unlink() for optimization? > > P.S. the code and short description of the FS I refer is here: > http://www.linux-mtd.infradead.org/doc/ubifs.html Hmm, I'm just not sure whether unlink cannot somehow race with open (at least I don't see any lock that would prevent open while unlink is in progress)... Honza - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
