In Linux, the file system is an all-in-one directory tree.
UNMOUNT DISK IN LINUX WINDOWS
Windows assigns each volume a drive letter such as C: or D: and the file system for each volume is a tree of directories sitting below that drive letter. The above command will recursively list all symbolic links in a directory tree (here starting at /var) and filter out those names that point to a specific target mount point (here disk2).The file systems in Linux, macOS, and other Unix-like operating systems don’t use separate volume identifiers for storage devices in the way that, say, Windows does. Next time I will look more closely at the output of: ls -lR /var | grep ^l | grep disk2 When I removed the symlink and updated the postfix and dovecot config files to point directly to the new dirs on /disk2/pers/ I was able to successfully stop the services and unmount the directory.
With this symlink, even after stopping the postfix and dovecot services (both ps aux as well as netstat -tuanp didn't show anything related) I was not able to unmount /disk2/pers. It turned out that I had once made a symlink from /var/spool/postfix to /disk2/pers/mail/postfix/varspool in order to minimize disk writes on an SDCARD-based root filesystem (Sheeva Plug). old and rebooting the system every time after I made changes I found one particular directory (relating to postfix) that was responsible. Lsof and fuser didn't give me anything either.Īfter a process of renaming all possible directories to. They won't appear in lsof +f - /dev/, so you'll need to: lsof | grep a_inodeįor killing processes holding anonymous inodes, see: List current inotify watches (pathname, PID). These are the most elusive type of pokemon, and appear in lsof's TYPE column as a_inode (which is undocumented in the lsof man page). Check with: mount | grep /įor loopback mounts, also check the output of: losetup -la Another filesystem mounted on the filesystem you are trying to umount will cause grief. Interactively kill only processes with files open for writing: fuser -vmMkiw Īfter remounting read-only ( mount -o remount,ro ), it is safe(r) to kill all remaining processes: fuser -vmMk List files on (see caveat above): fuser -vmM However fuser is useful when it comes to killing the processes causing your dramas so you can get on with your life. There is an advantage to using /dev/ rather than /mountpoint: a mountpoint will disappear after an umount -l, or it may be hidden by an overlaid mount.įuser can also be used, but to my mind lsof has a more useful output. Processes with open files are the usual culprits. I'm not sure whether quotas could ever prevent an unmount - I was clutching at straws. dev/loop1: :59 (/mnt/big/dot-dropbox.ext2)Ī Gentoo forum post also lists swapfiles as a potential culprit although swapping to files is probably pretty rare these days, it can't hurt to check the output of cat /proc/swaps. dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=er 0 0 Usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0ĭevpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0įusectl /sys/fs/fuse/connections fusectl rw 0 0 Tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0 dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0 None /proc proc rw,nosuid,nodev,noexec 0 0 None /sys sysfs rw,nosuid,nodev,noexec 0 0 I'd already checked the output of fuser -vm / lsof +D, mount and cat /proc/mounts, checked whether some old nfs-kernel-server was running, turned off quotas, attempted (but failed) a umount -f and all but resigned myself to abandoning 924 days' uptime before finally checking the output of losetup and finding two stale configured-but-not-mounted loopbacks: parsley:/mnt# cat /proc/mounts To add to BruceCran's comment above, the cause for my manifestation of this problem just now was a stale loopback mount.
0 kommentar(er)
