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. Thanks & Regards, Amit Sahrawat On Tue, Sep 6, 2011 at 10:56 PM, Amit Sahrawat <amit.sahrawat83@xxxxxxxxx> wrote: > We have observed below issues in busybox umount: > 1. force umount (umount -f): it does not work as expected. > 2. lazy umount(umount -l): it detaches the mount point but waits for > current mount point users(processes) to finish. > Corruption happens when we powerdown, while lazy umount is waiting for > a process to finish. > (e.g. #dd if=/dev/zero of=/mnt/test.txt ). > What could be the ideal way so as to avoid file system corruption in > above scenario? > Is it fine to close all open file descriptors on umount system call > before attempting umount? But this results in OOPS in certain > situations like: > 1. User app issue a write/read request > 2. Write reaches in kernel space but sleeps for some time e.g. it is > not available in dentry cache. > 3. In the meanwhile, we issue umount. This will close open file > descriptor, free file/dentry object and then umount. > 4. Now write wakes up and finds NULL file/dentry object and triggers oops. > Please offer some advice on this issue. > Thanks & Regards, > Amit Sahrawat > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
