Rsync & Finder hang; cannot remove unmounted volumes (Tiger) |
escoles 10-07-2005, 08:03 AM I'm having a problem removing unmounted volumes. I've tried umount and the "eject" parameter for diskutil; I've tried using diskutil GUI; I've tried Finder; the volumes still remain, like permanent graffitti, in my /volumes directory.
Here's the scenario:
I mount an external drive, either via firewire or USB. I use rsync or Finder to copy a bunch of stuff to it; eventually, rsync craps out or the copy operation just stops working, but the disk appears to still be mounted. If I make the mistake of trying to get a directory listing via Finder, Finder will hang. At that point, Finder cannot be relaunched unless the disk is PHYSICALLY unmounted.
Here's what I've tried PRIOR TO physically unmounting:
I've tried unmounting using Finder, before trying to display a directory listing. Finder hangs.
I've tried using umount (yes, I used sudo). umount hangs the terminal session -- can't be terminated. If I terminate the terminal session, that umount process hangs out there and can't be killed, even by root.
I've tried using the Diskutil gui to unmount. The disk ummounts from Finder, but still shows up as an entry in /volumes. (This is a problem because it causes the drive to mount with a different name in future sessions -- e.g., if volume is "aksea", it will mount in future sessions as "aksea 1". That makes it useless from an automated scripting perspective.)
[Aside: Those phantom disks in the volumes directory have a strange relationship with rsync. If I run rsync to copy to those volumes, it executes with no errors as though it's copying everything hunky-dory; it will even execute on subsequent iterations in the same terminal session as though it *has* copied everything hunky-dory. Of course, nothing has actually happened, because the volume is a phantom -- it has no content.]
If Finder is hung, or rsync is hung, I can usually (but not always) get Finder to finish relaunching or rsync to terminate by physically unmounting (i.e., power-cycling or unplugging) the external drive.
Here's what I've tried to do to remove the phantom /volume entries:
I've tried passing the "eject" switch to diskutil in the terminal (with sudo, so as root). It returns the error message "Volume failed to eject."
I've tried umount. It tells me that the volume isn't currently mounted.
Any suggestions? I've seen related issues come up, but the solutions posted for them just don't work for my situation.
Special note: I'm thinking this is most likely not a Tiger problem. I had some of these experiences prior to upgrading -- that's one of the reasons I upgraded, hoping that the external device support would improve (rather, suspecting that there wouldn't be improvements in Panther's).
escoles 10-07-2005, 08:06 AM Forgot: System is a 1gb Mini; this happens with a Seagate 300GB external on the Firewire port, and an Archos 20GB external USB drive. I have avioded attaching either of these drives to my PowerBook as I want to avoid this problem on that system.
escoles 10-07-2005, 08:41 AM I've found a partial answer in being able to remove the offending "ghost" volumes -- turns out they had content, after all. (Because it's so small, I didn't hear the internal drive thrashing when rsync was running.)
I suppose I'll just have to watch this very carefully, maybe write some cleanup scripts for when this happens in the future. It would still be nice to know why umount would hang the system; how to get Finder to relaunch without hard-restarting; and why the volume names persist and become virtual volumes on the internal drive, and most importantly, how to prevent it from happening again.
derekhed 10-07-2005, 01:33 PM Have you tried running lsof to see what files might be in use on those volumes? I know the man page is pretty long, I usually just grep for the information I am after.
escoles 10-08-2005, 05:58 AM Are you thinking that the disks would fail to dismount because of open files?
I haven't run lsof (this is the first I've heard of it), but I wouldn't expect that anything except rsync would be using files on the target drive. For the drives I'm talking about, I never open files or use applications stored on those drives -- they're purely for backup, at least when they're mounted on the Mac.
I'm finding that the Mac doesn't allow long term stable mounting of some UMS and Firewire devices. My Seagate drive, for example, isn't reliably found on startup, and (as I've said) will tend to stop working after I rsync a lot of files to it. My Arcos external drive mounts reliably, but can't be used with rsync, and will sometimes stop working if I transfer a lot of stuff to it. (I've been using Dirsync the past week or so; before that, I just copied in Finder, which leaves something to be desired.)
derekhed 10-10-2005, 02:01 PM The problems that I have run into in the past seem different than what you are describing. The only times I have had trouble unmounting a drive is when some files on it were in use, or when I had a Terminal window open and happened to be cd'ed onto the drive itself. In that case, there was no feedback, the drive just refused to unmount.
I have not had any trouble with long-term use of attached drives. I have a server with 2-3 drives attached to it all the time running 24/7 without incident - rsyncs included. I use RsyncX, FWIW.
Is there anything unusual about your rig? Do you have any opportunity to try different cables?
|
|
|
|
|
TOP
