lkml.org 
[lkml]   [2011]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Issue with lazy umount and closing file descriptor in between
On Wed, Sep 7, 2011 at 12:37, Amit Sahrawat <amit.sahrawat83@gmail.com> wrote:
> I know that lazy umount was designed keeping in mind that the
> mountpoint is not accesible to all future I/O but for the ongoing I/O
> it will continute to work. It is only after the I/O is finished that
> the umount will actually occur. But this can be tricky at times
> considering there are situations where the operation will continue to
> be executed than what is expected duration, and you cannot unplug the
> device during that period because there are chances of filesystem
> corruption on doing so.
> Is there anything which could be done in this context? because simply
> reading the fd-table and closing fd's will not serve the purpose and
> there is every chance of a OOPs occuring due to this closing.
> Signalling from this point to the all the process's with open fd's on
> that mountpoint to close fd i.e., handling needs to be done from the
> user space applications...? Does this make sense
>
> Please through some insight into this. I am not looking for exact
> solution it is just mere opinion's on this that can add to this.

Essentially what you want here is a 'forced unmount' option.

It's difficult to do this directly in the existing VFS model; you'd
need to essentially change the operations structure for all open
files/inodes for that filesystem in a race-free manner, _and_ wait for
any outstanding operations to complete. The VFS isn't really designed
to support something like this. What you could try doing, however, is
creating a wrapper filesystem - one that redirects all requests to an
underlying filesystem, but supports an operation to:

1) Make all future requests fail with -EIO
2) Invalidate any existing VMA mappings
3) Wait for all outstanding requests to complete
4) Unmount (ie, unreference) the underlying filesystem

This will result in some overhead, of course, but would seem to be the
safest route.


\
 
 \ /
  Last update: 2011-09-12 00:03    [W:1.318 / U:1.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site