Re: [RFC] freeing unliked file indefinitely delayed

2015-07-09 Thread Ian Kent
On Thu, 2015-07-09 at 19:17 +0800, Ian Kent wrote: > On Wed, 2015-07-08 at 02:42 +0100, Al Viro wrote: > > Normally opening a file, unlinking it and then closing will have > > the inode freed upon close() (provided that it's not otherwise busy and > > has no remaining links, of course). Howeve

Re: [RFC] freeing unliked file indefinitely delayed

2015-07-09 Thread Ian Kent
On Wed, 2015-07-08 at 02:42 +0100, Al Viro wrote: > Normally opening a file, unlinking it and then closing will have > the inode freed upon close() (provided that it's not otherwise busy and > has no remaining links, of course). However, there's one case where that > does *not* happen. Name

Re: [RFC] freeing unliked file indefinitely delayed

2015-07-08 Thread Ben Myers
Hey Al, On Wed, Jul 08, 2015 at 02:42:38AM +0100, Al Viro wrote: > Normally opening a file, unlinking it and then closing will have > the inode freed upon close() (provided that it's not otherwise busy and > has no remaining links, of course). However, there's one case where that > does *no

Re: [RFC] freeing unliked file indefinitely delayed

2015-07-07 Thread J. Bruce Fields
On Wed, Jul 08, 2015 at 02:42:38AM +0100, Al Viro wrote: > Normally opening a file, unlinking it and then closing will have > the inode freed upon close() (provided that it's not otherwise busy and > has no remaining links, of course). However, there's one case where that > does *not* happen