Date: Wed, 14 Jun 2006 16:15:57 -0400 From: Christopher Sean Hilton <chris@vindaloo.com> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: unmounting a filesystem safely that doesn't exist anymore Message-ID: <20060614201557.GC1537@dagobah.vindaloo.com> Resent-Message-ID: <200606142020.k5EKKNUG002533@dagobah.vindaloo.com> In-Reply-To: <5f67a8c40606121344g18d53ce9x4038384a734c3ce0@mail.gmail.com> References: <448B0419.3090303@cs.tu-berlin.de> <20060612193427.GE1226@roadrunner.aventurien.local> <5f67a8c40606121344g18d53ce9x4038384a734c3ce0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 12, 2006 at 04:44:48PM -0400, Zaphod Beeblebrox wrote:
> On 6/12/06, Ulrich Spoerlein <uspoerlein@gmail.com> wrote:
> >
> >Björn König wrote:
> >
>
>
> >> I did a mistake: I unplugged my digital camera accidentally before I
> >unmounted the
> >> filesystem. *doh* This happens very often, because I'm very
> >scatterbrained. =) The kernel
> >> will panic and all filesystems remain unclean in any case now. I know
> >that this is a well
> >> know issue and in past discussions you stated that this behaviour is
> >intended and won't be
> >> changed ad hoc. I just want to know if somebody knows a workaround or
> >small trick that
> >> prevents the other filesystems from being unclean on next boot-up.
> >
> >You might give the automounter (am-utils) a whirl. They are very
> >confusing to set up, but you can set the unmount-if-unused timeout to
> >something like 5 seconds. This could narrow the window enough to not
> >panic you system frequently :)
>
>
> That's rather hackish ... especially since this is a common problem and a
> rather obvious hole in using FreeBSD for noobs.
>
I've been using the automounter to handle these mounts for about three
years now. When I started I would be have to run fsck on my memory
stick about twice a day. Now it's more like once a month. In short it
works.
I've got to admit that I agree with the fact that this is a more than
rather hackish solution to the problem. The real issue here is that
for Unix, filesystems come in two types: Those on hard disks which are
perpetually available once they've been mounted once, and those which
come from the network which can come and go as they please. The
automounter works as a solution to this problem by making a local
filesystem on hotplugable hardware look like it's coming from a
network.
It took me the better part of a day to figure out how to make the
automounter work properly in this situation. In my case I was using a
UFS formatted memory stick which complicated things. The automounter
was coded with the assumption that UFS filesystems only exist on
drives that are bolted into the computer. The automounter will gladly
mount a UFS volume but because it's a UFS volume it never feels the
need to dismount the volume and leave it in a clean state.
Another problem is that most tools today makes a similar the
assumption about mounted volumes that they didn't graft into the
filesystem. So, for example opening up the Nautilus file browser on
/amd/ufs0 on my system creates an entry in some magic file somewhere
that tells Nautilus to periodically visit that directory. As far as
amd is concerned these visits are valid requests to mount the
filesystem. The end result is that the filesystem again remains
permanently mounted.
With MS-DOS FAT filesystems the problem is who mounted the
filesystem. Amd mounts my MP3 player read-write on /amd/mp3 perms 777
root:wheel. I use rsync to copy podcasts from a holding directory on
my desktop to it. And rsync complains all the time that it can copy
the files but it cannot change the date/time. This is because
chris:chris cannot change an entry in a directory owned by root:wheel,
as it should be.
It doesn't sound like I'm trying to sell this but in the long run I
actually believe that amd is the best of a bunch of mediocre
solutions. I wish however that:
Amd didn't make the assumption that a UFS volume was going to be
there forever;
Gnome could be told that filesystems under /amd or some other
programmable mount point will come and go with the wind so don't
cache the names;
That more applications would understand that there are people
using the automounter and that a mount request can be
accomplished by a simple:
$ ls -l /amd/foo
and a umount request can be accomplished by a doing:
$ amq -u /amd/foo
Look for a followup with configs.g
-- Chris
--
Chris Hilton chris-at-vindaloo-dot-com
------------------------------------------------------------------------
"All I was doing was trying to get home from work!"
-- Rosa Parks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060614201557.GC1537>