lkml.org 
[lkml]   [2012]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: deferring __fput()
On Mon, Jun 25, 2012 at 03:19:56PM +0200, Peter Zijlstra wrote:

> > I'll need to reread that thread to comment on the specifics (had been too long ago; I don't
> > remember the details), but... See Linus' objections to full-async fput() circa this April
> > or March. There's a reason why this patchset uses task_work_add() whenever possible.
>
> Ok, I'll try and find that thread, so the advantage of task_work_add()
> is that you'll keep the work in the task that caused it wherever
> possible, right -- provided its actually sitll around.
>
> If we make fput() deferable in general we'll be sure to grow some 'fun'
> cases. So are we going to add a sync against unmount someplace to avoid
> these un-expected -EBUSY things?

No. We are not. And I don't care how tasty some application might be -
this way madness lies. If you have _anything_ doing async fput() (which is
perfectly possible with the current mainline), you have to live with the
fact that yes, filesystem will be busy while your mechanism, whatever it
might be, is in use.

BTW, you do realize that delayed fput() may mean delayed fs shutdown?
Think of umount -l while you have an opened file...


\
 
 \ /
  Last update: 2012-06-25 16:42    [W:0.149 / U:1.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site