Timeline for umount failed: device busy
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 1, 2013 at 15:30 | comment | added | Andrew | So, I would only have suggested on waving the dead chicken to keep my head dry, not to stop the rain. Don't put words in my mouth, lol. Similarly, I said sync will get the filesystem unmount faster because that is what the 'busy' is awaiting. I got the filesystem unmounted, and my head remained dry. Both worked, as advertised. | |
| Oct 1, 2013 at 15:14 | comment | added | Gilles 'SO- stop being evil' | @Dor That answer is wrong, mpez0 has it right. See our question on the topic. | |
| Oct 1, 2013 at 15:12 | comment | added | Gilles 'SO- stop being evil' | @Andrew Running sync to make umount work is as efficient as waving a dead chicken to prevent rain: it doesn't, but it might prevent your head from getting wet. A lazy unmount does something different: it leaves the filesystem mounted, but at a different, unreachable location. So files can no longer be opened, but processes with open files are not affected. The filesystem is later unmounted when the last open descriptor is closed. For a ramfs, it frees the mount point, but does not free the memory until later. This is probably good enough. P.S. It doesn't rhyme, Gilles is pronounced like Gil. | |
| Oct 1, 2013 at 14:56 | comment | added | Andrew | @Dor - sync command runs as quickly as the disk can write, usually a few milliseconds or less. It has nothing to do with 'creating a delay'. Since it kills Gilles (rhyming intended) to manually invoke sync, use "umount -l" which is a lazy umount and you can probably skip the sync command. From the man page "Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore". No guarantee a lazy umount will work as well as sync, and/or not corrupt your /tmp filesystem, but you can try it. | |
| Oct 1, 2013 at 13:12 | comment | added | Dor | @Gilles: Please see the answer of the user 'jeberle' here. What is your opinion? | |
| Oct 1, 2013 at 10:08 | comment | added | Gilles 'SO- stop being evil' | @Dor You could test it by suspending all writes (noflushd does that, but I'm not sure if it would be suitable here, as it's fairly tied to the disk layer and to the way certain filesystems operate). If sleep works as a delay even when no syncing happens, this would demonstrate that sync is not needed. Alternatively, you can use logic: syncing is one of the first things that happens during the unmounting process. | |
| Oct 1, 2013 at 10:01 | comment | added | Dor | @Gilles: How can I test this..? I executed time on the sync and got the output: real 0m0.261s user 0m0.000s sys 0m0.020s | |
| Sep 30, 2013 at 21:46 | comment | added | Gilles 'SO- stop being evil' | No, you never need to call sync before umount. Calling sync just happens to delay the unmounting enough; calling sleep would do the same. | |
| Sep 30, 2013 at 20:39 | comment | added | Dor | You were right, I used sync before the umount and it works properly! Thank you! | |
| Sep 30, 2013 at 20:38 | vote | accept | Dor | ||
| Oct 1, 2013 at 13:18 | |||||
| Sep 30, 2013 at 18:53 | history | answered | Andrew | CC BY-SA 3.0 |