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).

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.

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. Namely,

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). However,

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

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 *not*

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*

[RFC] freeing unliked file indefinitely delayed

2015-07-07 Thread Al Viro
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. Namely, if you open it by fhandle with cold dcache, then

[RFC] freeing unliked file indefinitely delayed

2015-07-07 Thread Al Viro
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. Namely, if you open it by fhandle with cold dcache, then

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.