Re: is the inode an orphan?

[Artem Bityutskiy]

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.

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

Thanks!

--
Best Regards,
Artem Bityutskiy (ÐÑÑÑÐ ÐÐÑÑÑÐÐÐ)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/