On Tue, Oct 22, 2013 at 06:22:49PM +0100, Al Viro wrote: > On Sun, Oct 20, 2013 at 11:33:56AM +0100, Phil Davis wrote: > > > The reason I think btrfs send is leaking open files is if you watch > > /proc/sys/fs/file-nr you see the > > number of open files increasing but if you kill the btrfs send > > process then the open > > files count reduces back down. In fact suspending the process also > > reduces the open file count but > > resuming it then makes the count start increasing again. > > What does lsof show while you are running that? AFAICS, btrfs_ioctl_send() > should be neutral wrt file references - we do fget() on entry and > fput() of the result on exit, with nothing else looking relevant in > sight...
Agreed, the fget/fput of sctx->send_filp doesn't seem interesting. There's only one possible delayed fput() for each ioctl. I haven't *really* followed the delayed fput mechanics.. are we worried about a ton of delayed fputs building up before the ioctl returns to user space? The sctx->cur_inode_filp is opened and closed for each file that differs between the two trees such that the destination is brought up to date by writing. That can be O(storage) files if the source snapshot is empty and the destination snapshot is a full file system. All in one ioctl. Sooooo, put whatever call it is that synchronizes the delayed fputs in close_cur_inode_file() and see if the leak persists? - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
