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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
