removing external usb hdd without unmounting causes reboot?

8 views
Skip to first unread message

Momchil Ivanov

unread,
Jul 18, 2007, 5:45:47 AM7/18/07
to
Hi,

I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007 and=20
accidently unplugged the USB hub to which my external hdd together with a=20
mouse were connected and this caused my machine to freeze for some seconds=
=20
and then reboot. At that moment the hdd was mounted and I was playing music=
=20
out of it.
After that I tried to reproduce it :) so just plugged only the hdd directly=
,=20
mounted it and started playing music files from it. When I unplugged the US=
B=20
cable the same thing happened: short freeze, and then reboot.
Is this expected behaviour? And is there some way to avoid the freeze and=20
reboot?

Thanks.

=2D-=20
PGP KeyID: 0x3118168B
Keyserver: pgp.mit.edu
Key fingerprint BB50 2983 0714 36DC D02E =C2=A0158A E03D 56DA 3118 168B
=20
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

Mark Linimon

unread,
Jul 18, 2007, 9:43:08 AM7/18/07
to
On Wed, Jul 18, 2007 at 11:42:26AM +0200, Momchil Ivanov wrote:
> accidently unplugged the USB hub to which my external hdd together with a
> mouse were connected and this caused my machine to freeze for some seconds
> and then reboot.

Yes, this is a known problem, for which there is no workaround at the moment.

mcl

Josh Paetzel

unread,
Jul 18, 2007, 9:46:25 AM7/18/07
to
--nextPart2519369.ujUClLtp6T
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 18 July 2007, Momchil Ivanov wrote:
> Hi,
>
> I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007

> and accidently unplugged the USB hub to which my external hdd


> together with a mouse were connected and this caused my machine to

> freeze for some seconds and then reboot. At that moment the hdd was
> mounted and I was playing music out of it.


> After that I tried to reproduce it :) so just plugged only the hdd

> directly, mounted it and started playing music files from it. When
> I unplugged the USB cable the same thing happened: short freeze,


> and then reboot. Is this expected behaviour? And is there some way

> to avoid the freeze and reboot?
>
> Thanks.

Yes, it's expected behavior. The workaround is to not unplug mounted=20
devices. (There's nothing special about USB here, if you unplugged an=20
IDE drive you'd get the same behavior)

=2D-=20
Thanks,

Josh Paetzel

--nextPart2519369.ujUClLtp6T
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQBGnhgmJvkB8SevrssRAnUOAKCUUDUZbgXIydtuibZdYmXOIXLbPgCfS1Bd
p9r+9dVhdqbkV4HqI1s5sm8=
=Xt8W
-----END PGP SIGNATURE-----

--nextPart2519369.ujUClLtp6T--

[LoN]Kamikaze

unread,
Jul 18, 2007, 10:22:13 AM7/18/07
to
Josh Paetzel wrote:
> On Wednesday 18 July 2007, Momchil Ivanov wrote:
>> Hi,
>>
>> I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007
>> and accidently unplugged the USB hub to which my external hdd
>> together with a mouse were connected and this caused my machine to
>> freeze for some seconds and then reboot. At that moment the hdd was
>> mounted and I was playing music out of it.
>> After that I tried to reproduce it :) so just plugged only the hdd
>> directly, mounted it and started playing music files from it. When
>> I unplugged the USB cable the same thing happened: short freeze,
>> and then reboot. Is this expected behaviour? And is there some way
>> to avoid the freeze and reboot?
>>
>> Thanks.
>
> Yes, it's expected behavior. The workaround is to not unplug mounted
> devices. (There's nothing special about USB here, if you unplugged an
> IDE drive you'd get the same behavior)
>

Wouldn't it make some sense not to panic if mounted devices that are in sync
get removed? A few applications might get in trouble, but that's hardly a
reason to bring a whole system down.

Momchil Ivanov

unread,
Jul 18, 2007, 11:06:56 AM7/18/07
to
--nextPart2548977.AsHXLgMVcJ

Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote:
> Josh Paetzel wrote:
> > On Wednesday 18 July 2007, Momchil Ivanov wrote:
> >> Hi,
> >>
> >> I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007
> >> and accidently unplugged the USB hub to which my external hdd
> >> together with a mouse were connected and this caused my machine to
> >> freeze for some seconds and then reboot. At that moment the hdd was
> >> mounted and I was playing music out of it.
> >> After that I tried to reproduce it :) so just plugged only the hdd
> >> directly, mounted it and started playing music files from it. When
> >> I unplugged the USB cable the same thing happened: short freeze,
> >> and then reboot. Is this expected behaviour? And is there some way
> >> to avoid the freeze and reboot?
> >>
> >> Thanks.
> >
> > Yes, it's expected behavior. The workaround is to not unplug mounted
> > devices. (There's nothing special about USB here, if you unplugged an
> > IDE drive you'd get the same behavior)
>
> Wouldn't it make some sense not to panic if mounted devices that are in
> sync get removed? A few applications might get in trouble, but that's
> hardly a reason to bring a whole system down.

I don`t know how things work, but shutting down the system when some mounte=
d=20
fs is no longer present seems like the wrong thing to me. It`s surely safe =
:)=20
just bring everything down in order to ensure not messing things ups. But=20
nowadays there are a lot of USB devices and umounting every time is somethi=
ng=20
that one is surely going to forget once and ooops everyting goes down.
If the same thing happens when a network fs is mounted (say NFS or SMBFS) a=
nd=20
then becomes unavailable due to network outages (wireless connections break=
=20
easily compared to cable connections, and nowadays the former become=20
popular), then I think it should be fixed.
"Windows" doesn`t reboot if you unplug the usb or network cable, which I th=
ink=20
is the right way of handling these kind of situations.

Idea: do something like "umount -f" when a fs becomes unavailabe, just tell=
=20
every program that files are unaccessible?

I don`t have the programming skills and knowledge of how freebsd works, tha=
t`s=20
why I can only help with feedback and ideas :) Shutting down the system=20
without user`s desire seems like a problem to me, regardless of the reason.=
=20
And problems are there to be solved.

=2D-=20
PGP KeyID: 0x3118168B
Keyserver: pgp.mit.edu
Key fingerprint BB50 2983 0714 36DC D02E =C2=A0158A E03D 56DA 3118 168B
=20

--nextPart2548977.AsHXLgMVcJ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQBGniuo4D1W2jEYFosRAiOOAJ9bd6dBvMqyU08i8yhJwfeuN5R1qwCgv5bz
0oycV3bKXoZsA3TM+xXbA2k=
=iyBn
-----END PGP SIGNATURE-----

--nextPart2548977.AsHXLgMVcJ--

Baldur Gislason

unread,
Jul 18, 2007, 11:24:31 AM7/18/07
to
I vaguely remember being able to yank out USB drives in 5.x and just make
usbd execute a forced umount without any problems. FAT32 drives mind you.
On 6.2 I haven't even been able to unplug a USB drive even if I unmount it
first, always results in a kernel panic.

Baldur


On Wed, Jul 18, 2007 at 08:39:46AM -0500, Josh Paetzel wrote:
> On Wednesday 18 July 2007, Momchil Ivanov wrote:
> > Hi,
> >
> > I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007
> > and accidently unplugged the USB hub to which my external hdd
> > together with a mouse were connected and this caused my machine to
> > freeze for some seconds and then reboot. At that moment the hdd was
> > mounted and I was playing music out of it.
> > After that I tried to reproduce it :) so just plugged only the hdd
> > directly, mounted it and started playing music files from it. When
> > I unplugged the USB cable the same thing happened: short freeze,
> > and then reboot. Is this expected behaviour? And is there some way
> > to avoid the freeze and reboot?
> >
> > Thanks.
>
> Yes, it's expected behavior. The workaround is to not unplug mounted
> devices. (There's nothing special about USB here, if you unplugged an
> IDE drive you'd get the same behavior)
>

> --
> Thanks,
>
> Josh Paetzel

Oliver Fromme

unread,
Jul 18, 2007, 11:49:41 AM7/18/07
to
Momchil Ivanov wrote:
> On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote:
> > Josh Paetzel wrote:
> > > Yes, it's expected behavior. The workaround is to not unplug mounted
> > > devices. (There's nothing special about USB here, if you unplugged an
> > > IDE drive you'd get the same behavior)
> >
> > Wouldn't it make some sense not to panic if mounted devices that are in
> > sync get removed? A few applications might get in trouble, but that's
> > hardly a reason to bring a whole system down.
>
> I don`t know how things work, but shutting down the system when some
> mounted fs is no longer present seems like the wrong thing to me.

As Josh wrote, it's expected. The problem is known
to exist for a long time already (probably as long
as FreeBSD itself exists), and if there was an easy
solution, certainly someone would have fixed it.

Just remember to always umount first, and you're safe.
In the early 90s I panicked a FreeBSD machine by
removing a floppy disk that was mounted. I did that
mistake only once -- afterwards I always remembered.

If you have problems remembering, another work-around
is to use the auto mounter daemon (amd(8)). It umounts
file systems automatically that are not in use.
Another nice feature of amd(8) is that you don't have
to mount the file system either -- Simply plug the USB
stick in, then access it, and amd(8) will automatically
mount it for you.

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd

"I learned Java 3 years before Python. It was my language of
choice. It took me two weekends with Python before I was more
productive with it than with Java." -- Anthony Roberts

Jeremy Chadwick

unread,
Jul 18, 2007, 11:51:40 AM7/18/07
to
On Wed, Jul 18, 2007 at 05:03:03PM +0200, Momchil Ivanov wrote:
> "Windows" doesn`t reboot if you unplug the usb or network cable, which I think
> is the right way of handling these kind of situations.

Windows also (as of XP; I don't think it was this way in 2000) by
default disables read/write caching on all USB-plugged storage devices.

This was done because people were unplugging USB storage devices without
"shutting them down" (going to the systray and selecting the device then
choosing "Stop" to ensure all caches were flushed and data on the device
had been written). The performance hit is pretty major, but the
attitude is "safety first".

You can, of course, toggle the caching feature per device/drive, but
you'll need to Stop the device before removing it from the USB bus.

--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |

Momchil Ivanov

unread,
Jul 18, 2007, 12:34:44 PM7/18/07
to
--nextPart1265518.WP56TgVvPf
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 18 July 2007 17:41:04 Oliver Fromme wrote:
> As Josh wrote, it's expected. The problem is known
> to exist for a long time already (probably as long
> as FreeBSD itself exists), and if there was an easy
> solution, certainly someone would have fixed it.
>
> Just remember to always umount first, and you're safe.
> In the early 90s I panicked a FreeBSD machine by
> removing a floppy disk that was mounted. I did that
> mistake only once -- afterwards I always remembered.
>
> If you have problems remembering, another work-around
> is to use the auto mounter daemon (amd(8)). It umounts
> file systems automatically that are not in use.
> Another nice feature of amd(8) is that you don't have
> to mount the file system either -- Simply plug the USB
> stick in, then access it, and amd(8) will automatically
> mount it for you.
>
> Best regards
> Oliver

I started the thread just because it hit me today. I wanted to disconnect m=
y=20
mouse and forgot that the hdd is connected to the same hub, I realized that=
=20
after having unplugged the usb hub and saw the system freeze. I know that=20
this has been an issue for a long time. With cdroms it`s easy, the tray won=
`t=20
open until you umount the cd fs, floppies......... nowadays they have been=
=20
replaced by usb sticks, but they have no trays as cdroms do :) moreover=20
people use other usb storages too and unplugging those is just as simple as=
=20
unpluging the cable.

I think this is a critical problem and needs to be addressed, avoiding it=20
doesn`t solve it.

As technology advances I think FreeBSD has to advance too. You said you=20
paniced a system in the early 90s, which is more than 10 years from now. In=
=20
the past floppy disks were maybe the only problem, but nowadays as storage =
is=20
cheap more and more people use USB storage devices, and these are easy to=20
unplug. It`s even worse if you have a laptop, since it`s easier to connect=
=20
everything to a hub (mouse, hdds, other usb stuff) and connect/disconnect i=
t.

In the days before common storage devices (hard drives) where fixed inside =
the=20
computer`s case, so unpluging a hard drive when the computer was running wa=
s=20
considered as "insane", so panicing is ok. Nowadays things have changed. US=
B=20
(maybe Firewire too, have no experience with that) offers a simple way to=20
connect/disconnect devices to your computer (here I have to note: not just=
=20
one!), having a laptop and 1,2,3 or even more external storage devices is=20
something usual.
That`s why I think this particular problem needs to be addressed.

Thanks for the tip about amd(8) I will give it a try.

=2D-=20
PGP KeyID: 0x3118168B
Keyserver: pgp.mit.edu

Key fingerprint BB50 2983 0714 36DC D02E =A0158A E03D 56DA 3118 168B
=20

--nextPart1265518.WP56TgVvPf
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQBGnkA04D1W2jEYFosRApWeAKCUpMbhzRb7RfZ57u5wsXa6ssprzQCbB7Xg
zxcXV6bgn7JONu8h8xuptoQ=
=f6Ex
-----END PGP SIGNATURE-----

--nextPart1265518.WP56TgVvPf--

Baldur Gislason

unread,
Jul 18, 2007, 12:39:46 PM7/18/07
to
This really struck me as a problem when I had a short power outage and my external USB hard drive
wasn't plugged into the UPS. Laptop didn't reboot from the power outage but it rebooted
anyway because it lost a hard drive (which was mounted but I wasn't doing any work on)

Baldur

On Wed, Jul 18, 2007 at 06:30:44PM +0200, Momchil Ivanov wrote:
> On Wednesday 18 July 2007 17:41:04 Oliver Fromme wrote:
> > As Josh wrote, it's expected. The problem is known
> > to exist for a long time already (probably as long
> > as FreeBSD itself exists), and if there was an easy
> > solution, certainly someone would have fixed it.
> >
> > Just remember to always umount first, and you're safe.
> > In the early 90s I panicked a FreeBSD machine by
> > removing a floppy disk that was mounted. I did that
> > mistake only once -- afterwards I always remembered.
> >
> > If you have problems remembering, another work-around
> > is to use the auto mounter daemon (amd(8)). It umounts
> > file systems automatically that are not in use.
> > Another nice feature of amd(8) is that you don't have
> > to mount the file system either -- Simply plug the USB
> > stick in, then access it, and amd(8) will automatically
> > mount it for you.
> >
> > Best regards
> > Oliver
>

> I started the thread just because it hit me today. I wanted to disconnect my

> mouse and forgot that the hdd is connected to the same hub, I realized that

> after having unplugged the usb hub and saw the system freeze. I know that

> this has been an issue for a long time. With cdroms it`s easy, the tray won`t

> open until you umount the cd fs, floppies......... nowadays they have been

> replaced by usb sticks, but they have no trays as cdroms do :) moreover

> people use other usb storages too and unplugging those is just as simple as

> unpluging the cable.
>
> I think this is a critical problem and needs to be addressed, avoiding it

> doesn`t solve it.
>
> As technology advances I think FreeBSD has to advance too. You said you

> paniced a system in the early 90s, which is more than 10 years from now. In

> the past floppy disks were maybe the only problem, but nowadays as storage is

> cheap more and more people use USB storage devices, and these are easy to

> unplug. It`s even worse if you have a laptop, since it`s easier to connect

> everything to a hub (mouse, hdds, other usb stuff) and connect/disconnect it.
>
> In the days before common storage devices (hard drives) where fixed inside the
> computer`s case, so unpluging a hard drive when the computer was running was
> considered as "insane", so panicing is ok. Nowadays things have changed. USB

> (maybe Firewire too, have no experience with that) offers a simple way to

> connect/disconnect devices to your computer (here I have to note: not just

> one!), having a laptop and 1,2,3 or even more external storage devices is

> something usual.
> That`s why I think this particular problem needs to be addressed.
>
> Thanks for the tip about amd(8) I will give it a try.
>

> --

> PGP KeyID: 0x3118168B
> Keyserver: pgp.mit.edu

> Key fingerprint BB50 2983 0714 36DC D02E  158A E03D 56DA 3118 168B

Jeremy Chadwick

unread,
Jul 18, 2007, 1:10:25 PM7/18/07
to
On Wed, Jul 18, 2007 at 06:30:44PM +0200, Momchil Ivanov wrote:
> On Wednesday 18 July 2007 17:41:04 Oliver Fromme wrote:
> > As Josh wrote, it's expected. The problem is known
> > to exist for a long time already (probably as long
> > as FreeBSD itself exists), and if there was an easy
> > solution, certainly someone would have fixed it.
>
> I think this is a critical problem and needs to be addressed, avoiding it
> doesn`t solve it.

I agree.

I also have a hard time believing that the reason it hasn't been fixed
is because "there isn't an easy fix". I'm under the impression it
hasn't been fixed because either no one cares enough to fix it (using
the workaround as a scapegoat excuse), or because the majority of people
do not use USB-based storage devices.

All of this brings me back a few years when I went on a quest to write a
application that interfaced with a Logitech USB webcam for FreeBSD (for
a streaming fishtank camera). I found that USB alternative indexes were
broken (the code was there, but did not work), which the camera relied
upon. When I reported the issue to the FreeBSD USB stack maintainer at
the time (who will remain nameless since he enjoyed arguing rather than
fixing or working with me), I was told 2 things: "I just ported this
from NetBSD, don't blame me", "Alt. indexes aren't commonly used so I
don't really care".

So, based on my experience as documented above, I would say the reasons
I listed are dead on.

Bottom line here is that the kernel panics when removing a USB device
that has filesystems mounted. This shouldn't happen. Spitting out
errors on the console is one thing, but a panic is another. Sometimes
things cannot be avoided (re: "unmount and you'll be fine"), such as
cats pulling on USB hub AC power cables and other such things.

If someone wants to work on this and needs devices/toys (thumb drives,
external enclosures + hard disks), let me know, I will be more than
happy to buy them the hardware needed.

--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |

_______________________________________________

Mark Linimon

unread,
Jul 18, 2007, 1:39:07 PM7/18/07
to
On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote:
> Bottom line here is that the kernel panics when removing a USB device
> that has filesystems mounted.

s/USB //

> I also have a hard time believing that the reason it hasn't been fixed
> is because "there isn't an easy fix". I'm under the impression it
> hasn't been fixed because either no one cares enough to fix it (using
> the workaround as a scapegoat excuse), or because the majority of people
> do not use USB-based storage devices.

The reason is not the USB stack; the reason (IIRC) is that the FreeBSD
VM was written with the default assumption that Devices Never Go Away.
A large rewrite, I'm told, will be needed to fix this, and the code is
convoluted and tricky.

No one finds the situation acceptable; introducing the "scapegoat" word
isn't going to win you any support. The problem is not a weekend's worth
of work to fix, nor does it have anything to do with avoidance by one
particular maintainer, which you apparently had encountered before.

mcl

Zaphod Beeblebrox

unread,
Jul 18, 2007, 1:42:02 PM7/18/07
to
Nobody's said what the problem is. I'm not a filesystem code monkey, but
IIRC, the problem is that the filesystem plays fast and loose with pointers
and is too closely related to the VM.

One solution is (as mentioned) a userland filesystem that doesn't panic.
automount approximates this if you set the disconnect interval short (< 5
seconds).

The other way to look at this, though, is the general goal of "not panicing"
when it can be avoided. As a research OS, it's my feeling that BSD derived
unixes have followed the "if in doubt, panic" regime. I don't think this is
appropriate to a modern desktop or server OS.

To my mind, an OS should only panic if there are indications of hardware
corruption in a subsystem that can't be turned off. Ie: memory bad: panic;
controller bad, turn off controller.

In this particular case, we have unmount -f. If there are no dirty buffers,
the USB system triggering the equivalent of unomunt -f should succeed. If
we only mount usb devices async, this should be sufficient for most cases.
If there are dirty buffers, what do we loose by just forgetting about them?
The filesystem on the device is already as corrupt as its going to be...

Momchil Ivanov

unread,
Jul 18, 2007, 1:48:45 PM7/18/07
to
--nextPart1305907.FlWP3XjsCh

Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 18 July 2007 19:34:06 Mark Linimon wrote:
> On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote:
> > Bottom line here is that the kernel panics when removing a USB device
> > that has filesystems mounted.
>
> s/USB //

Just a dumb question: what does "umount -f" does? And doing something like=
=20
that when a fs goes away shouldn`t fix it?

If the problem is in general with a file system, regardless of the provider=
,=20
then what does one do when a mounted smbfs becomes unavailable due to remot=
e=20
host down, no route to host or some other network related problems? Same=20
question for NFS mounted filesystems?

=2D-=20


PGP KeyID: 0x3118168B
Keyserver: pgp.mit.edu

Key fingerprint BB50 2983 0714 36DC D02E =A0158A E03D 56DA 3118 168B
=20

--nextPart1305907.FlWP3XjsCh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQBGnlEQ4D1W2jEYFosRAgEuAJwOP8VRMGJ0Evo0+iC0GBpE3upX3ACfUwbt
1/3ZK9bniWJjrNKdY79ovpc=
=YkdT
-----END PGP SIGNATURE-----

--nextPart1305907.FlWP3XjsCh--

Kris Moore

unread,
Jul 18, 2007, 2:59:39 PM7/18/07
to

Momchil Ivanov wrote:
> On Wednesday 18 July 2007 19:34:06 Mark Linimon wrote:
>> On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote:
>>> Bottom line here is that the kernel panics when removing a USB device
>>> that has filesystems mounted.
>> s/USB //
>
> Just a dumb question: what does "umount -f" does? And doing something like

> that when a fs goes away shouldn`t fix it?
>

> If the problem is in general with a file system, regardless of the provider,
> then what does one do when a mounted smbfs becomes unavailable due to remote

> host down, no route to host or some other network related problems? Same

> question for NFS mounted filesystems?
>
>
>

> ------------------------------------------------------------------------
>
> !DSPAM:1,469e538b20763944420674!


Wow, quite a thread going on over this issue. I'll throw my 2cents into
the ring also :)

>From a desktop perspective, it makes total sense to not have the system
crash just because a USB disk was unplugged while mounted. When a new
end user does this for the first time and the system crashes, usually
the first thing they assume is that it's a bug. Then somebody like me
comes around and tells them to unmount it first. Then usually the next
thing they say is something along the lines of "That's so early 90's,
why can't you guys get your act together?"

I can understand requiring unmounting for devices such as CD's or
internal IDE / SCSI hard drives. With a CD at least you can physically
"lock" the drive bay to prevent the user from ejecting until unmounted
first. However, with a USB the ballgame changes, the whole concept is to
be hot-swappable, plugin and unplug at will. If a "normal" desktop user
copies a file to a USB disk and the file transfer dialog is done, then
they should be able to unplug it, without a total system crash.

That being said, I think it would be a good idea to at least have the
kernel / HAL or some process maybe warn the user that they should
unmount the USB disk first, to prevent data loss at minimum. But I think
this can be improved, so you don't have to deal with an entire system
panic :P When that happens you gotta reboot, fsck, and run the risk of
something really being corrupted on the drive :(


--

Kris Moore
PC-BSD Software
http://www.pcbsd.com

Josh Paetzel

unread,
Jul 18, 2007, 3:07:00 PM7/18/07
to
--nextPart3727139.BdYWivcdTr

Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 18 July 2007, Mark Linimon wrote:
> On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote:
> > Bottom line here is that the kernel panics when removing a USB
> > device that has filesystems mounted.
>
> s/USB //
>

> > I also have a hard time believing that the reason it hasn't been
> > fixed is because "there isn't an easy fix". I'm under the
> > impression it hasn't been fixed because either no one cares
> > enough to fix it (using the workaround as a scapegoat excuse), or
> > because the majority of people do not use USB-based storage
> > devices.
>
> The reason is not the USB stack; the reason (IIRC) is that the
> FreeBSD VM was written with the default assumption that Devices
> Never Go Away. A large rewrite, I'm told, will be needed to fix
> this, and the code is convoluted and tricky.
>
> No one finds the situation acceptable; introducing the "scapegoat"
> word isn't going to win you any support. The problem is not a
> weekend's worth of work to fix, nor does it have anything to do
> with avoidance by one particular maintainer, which you apparently
> had encountered before.
>
> mcl

Panicing really is the right thing to do with the current=20
architecture. Not panicing when a mounted filesystem disappears runs=20
the risk of corrupting other mounted filesystems.

Mark is entirely correct, FreeBSD faces an architecture problem here=20
in that the vm and filesystems we have today were not designed in an=20
era when they could just disappear from a running system. The BSD=20
way isn't to apply a quick and dirty little hack to fix=20
the 'problem', it's to design the system properly. And this is=20
assuming a quick and dirty hack even exists.

The other problem you're running in to with UFS anyways is that there=20
is no chance to 'unmount' the filesystem when you disconnect the=20
drive. By the time anything has a chance to realize it's gone it's=20
too late. Whether the disk is in the middle of a write, still has=20
buffers to be written out, or is perfectly clean and needs to just be=20
marked as such by the time the OS realizes any of that needs to be=20
done the drive is no longer physically connected to the computer.

What might need to happen is a redesign of the vm subsystem so that it=20
can safely deal with mounted filesystems going away, and designing a=20
filesystem that doesn't need to be unmounted specifically for=20
removeable devices. Doesn't sound trivial to me.

Or

You can just not remove devices with mounted filesystems from your=20
computer.....

=2D-=20
Thanks,

Josh Paetzel

--nextPart3727139.BdYWivcdTr
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQBGnmPxJvkB8SevrssRAlJnAKCKaBjMmBU8d/Po4GVrsTYN5YIk1wCfUO9F
T4cSR4SaVS6YdN1vEZ2cNOI=
=2U3K
-----END PGP SIGNATURE-----

--nextPart3727139.BdYWivcdTr--

Stefan Esser

unread,
Jul 18, 2007, 3:25:47 PM7/18/07
to
Oliver Fromme wrote:
> Momchil Ivanov wrote:
> > On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote:
> > > Josh Paetzel wrote:
> > > > Yes, it's expected behavior. The workaround is to not unplug mounted
> > > > devices. (There's nothing special about USB here, if you unplugged an
> > > > IDE drive you'd get the same behavior)
> > >
> > > Wouldn't it make some sense not to panic if mounted devices that are in
> > > sync get removed? A few applications might get in trouble, but that's
> > > hardly a reason to bring a whole system down.
> >
> > I don`t know how things work, but shutting down the system when some
> > mounted fs is no longer present seems like the wrong thing to me.
>
> As Josh wrote, it's expected. The problem is known
> to exist for a long time already (probably as long
> as FreeBSD itself exists), and if there was an easy
> solution, certainly someone would have fixed it.

I have to check this, but AFAIK this problem exists only for
devices/partitions that are mounted R/W. Do you happen to
know this? (I can not risk to crash my box right now for a
test ;-)

There once was an autofs implementation, but IIRC it has
later been removed. It could not only automatically mount
removable media, but it could also help with the problem
of devices that are rarely written to, but still mounted
R/W just in case for easy write-access.


Long time ago I had the idea that a clean file system could
be mounted R/O after a short delay. When all dirty buffers
are flushed, the device could be forcefully disconnected
without causing inconsistencies in the kernel. If there are
no open file descriptors, the super-block could be written
with the "clean" flag set, to signal that no fsck is needed
when the partition is mounted next time.

Internally, the device can be treated as R/O, with the only
exeption that an attempted write is not rejected, but that
it instead triggers the change back to R/W operation (this
means setting the in-RAM copy of the super-block to dirty
before the write is allowed to proceed as normal).

Removable devices and dealing with a device that is gone and
re-appears (either the same device or one that takes its place)
needs special consideration, e.g. by checking a disk label and
flushing cached blocks that were associated with the device
that now is definitely gone.

I had this idea back when floppy disks were common, but with
USB memory sticks and devices the same situation exists ...

The mode change to R/O could be triggered by a timer after
the necessary condition exists (e.g. half a second after the
last write to the device with no dirty buffers left).

The system already knows whether there are dirty buffers for
a partition, it is not hard to detect this case. The other
parameter of interest is whether there are any open files on
that partition (which decides whether the super-block can be
marked as clean).

This functionality could be implemented within an autofs as
a special case (mount only R/O and upgrade only when needed
and for as long as necessary), but I think it should be not
too hard to add as a small in-kernel modification ...

Regards, STefan

Jeremy Chadwick

unread,
Jul 18, 2007, 4:13:13 PM7/18/07
to
On Wed, Jul 18, 2007 at 11:54:19AM -0700, Kris Moore wrote:
> That being said, I think it would be a good idea to at least have the
> kernel / HAL or some process maybe warn the user that they should
> unmount the USB disk first, to prevent data loss at minimum. But I think
> this can be improved, so you don't have to deal with an entire system
> panic :P When that happens you gotta reboot, fsck, and run the risk of
> something really being corrupted on the drive :(

So there's two issues here:

1) Kernel panics when a device (regardless of type (USB, SATA, etc.))
is removed from the system with filesystems mounted,

2) Concern over data loss when device is removed.

As I mentioned earlier in the thread, Windows addresses #2 by marking
all filesystems on USB storage devices (thumb drives, HDDs, etc.) as
synchronous (e.g. mount -o sync). The impact is slow I/O, but it's
safe.

It seems like we'd be able to implement such a transparent "feature"
into the subsystem where filesystems mounted from USB devices would use
synchronous I/O (mount -o sync). I don't know how this would be coded,
since there would have to be some way to figure out a physical device
type (USB mass storage devices show up as /dev/daXXX).

Providing an override option for those who know what they're doing,
(umount /mnt then physically remove device) would be nice too.

This would alleviate concerns over data loss, would it not?

--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |

_______________________________________________

Ivan Voras

unread,
Jul 18, 2007, 4:34:25 PM7/18/07
to
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDF95000B3159C5CB0DBA090D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Zaphod Beeblebrox wrote:

> One solution is (as mentioned) a userland filesystem that doesn't panic=
=2E
> automount approximates this if you set the disconnect interval short (<=
5
> seconds).

Unfortunately the approximation is far from perfect because it takes
noticable time to mount a msdosfs on large drives (I think the FAT is
being read?).

> The other way to look at this, though, is the general goal of "not
> panicing"

> when it can be avoided. As a research OS, it's my feeling that BSD der=


ived
> unixes have followed the "if in doubt, panic" regime. I don't think
> this is
> appropriate to a modern desktop or server OS.

Agreed very much, though some of the older hackers here seem to like the
old approach.


--------------enigDF95000B3159C5CB0DBA090D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGnnh3ldnAQVacBcgRApuFAJ9xLjx4tSGVBuawXefYS4CO615fngCfRuy2
aZmzTMl0+aP2fGdibTRRhuU=
=IvRz
-----END PGP SIGNATURE-----

--------------enigDF95000B3159C5CB0DBA090D--

Kris Moore

unread,
Jul 18, 2007, 4:37:27 PM7/18/07
to
Jeremy Chadwick wrote:
> On Wed, Jul 18, 2007 at 11:54:19AM -0700, Kris Moore wrote:
>> That being said, I think it would be a good idea to at least have the
>> kernel / HAL or some process maybe warn the user that they should
>> unmount the USB disk first, to prevent data loss at minimum. But I think
>> this can be improved, so you don't have to deal with an entire system
>> panic :P When that happens you gotta reboot, fsck, and run the risk of
>> something really being corrupted on the drive :(
>
> So there's two issues here:
>
> 1) Kernel panics when a device (regardless of type (USB, SATA, etc.))
> is removed from the system with filesystems mounted,
>
> 2) Concern over data loss when device is removed.
>
> As I mentioned earlier in the thread, Windows addresses #2 by marking
> all filesystems on USB storage devices (thumb drives, HDDs, etc.) as
> synchronous (e.g. mount -o sync). The impact is slow I/O, but it's
> safe.
>
> It seems like we'd be able to implement such a transparent "feature"
> into the subsystem where filesystems mounted from USB devices would use
> synchronous I/O (mount -o sync). I don't know how this would be coded,
> since there would have to be some way to figure out a physical device
> type (USB mass storage devices show up as /dev/daXXX).
>
> Providing an override option for those who know what they're doing,
> (umount /mnt then physically remove device) would be nice too.
>
> This would alleviate concerns over data loss, would it not?
>

This sounds like an excellent idea to me. If something along these lines
were implemented, it would be very helpful for us on the desktop end of
things.

--

Kris Moore
PC-BSD Software
http://www.pcbsd.com

Ivan Voras

unread,
Jul 18, 2007, 4:41:56 PM7/18/07
to
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5CC8270F794670374466D5F7

Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Josh Paetzel wrote:

> designing a=20
> filesystem that doesn't need to be unmounted specifically for=20

> removeable devices. =20

Or just do what Windows does on its hard-drive-mounted NTFS and MSDOS
file systems and mark it clean after several seconds of inactivity. This
also helps solve other problems like power failures, laptop battery
drainage (in its common form and when the battery dies while the system
is suspened).

--------------enig5CC8270F794670374466D5F7


Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGnnodldnAQVacBcgRAgT2AKDulXH/WxdsNNoSfRq2BMK4ExofaACg3ogV
BMOIwZojV22GagUPPlXQ7b8=
=7BoV
-----END PGP SIGNATURE-----

--------------enig5CC8270F794670374466D5F7--

Ivan Voras

unread,
Jul 18, 2007, 4:50:26 PM7/18/07
to
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig72D3E7F327F40266C670C4C1

Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Mark Linimon wrote:

> The reason is not the USB stack; the reason (IIRC) is that the FreeBSD
> VM was written with the default assumption that Devices Never Go Away.
> A large rewrite, I'm told, will be needed to fix this, and the code is
> convoluted and tricky.

I also feel that the "institutial knowledge" about the VM+VFS+UFS
conglomerate seems to be going away. There were many attempts to port
file systems to FreeBSD that have stopped dead once they've reached
read-only phase, and recent problems with UFS looked really ugly (I
don't even know if they are solved - I'm scared of filling up UFS drives
right now :) ). My first production ZFS panicked the other day so ZFS is
not yet the answer.

(And yes, I know I'm complaining without suggesting solutions).


--------------enig72D3E7F327F40266C670C4C1


Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGnnwMldnAQVacBcgRAsKeAKDJ9hFk5HqQT33Y80SHGrqG8zzLfQCg4omY
hf/RXcdEOs0jhLouP20ML1Y=
=Tt5T
-----END PGP SIGNATURE-----

--------------enig72D3E7F327F40266C670C4C1--

Don Lewis

unread,
Jul 18, 2007, 6:20:37 PM7/18/07
to
On 18 Jul, Momchil Ivanov wrote:

> If the problem is in general with a file system, regardless of the provider,
> then what does one do when a mounted smbfs becomes unavailable due to remote
> host down, no route to host or some other network related problems? Same
> question for NFS mounted filesystems?

In the case of NFS, nothing happens if the filesystem is idle. If the
filesystem is active, any pending operations are retried indefinitely by
periodically resending the I/O requests if the file system is hard
mounted. If the filesystem is soft mounted, then the I/O requests are
eventually timed out with the appropriate error status returned to the
process on the client.

An important difference between NFS and UFS is that a loss of network
connectivity (or a clean server reboot) can't cause any filesystem
inconsistencies in the NFS case because complex filesystem operations
that require multiple disk operations are treated as atomic operations
between the client and server. For example, creating a new directory
requires a number of physical disk writes in the UFS case, and
unplugging the disk in the middle would result in an inconsistent
filesystem state. In the NFS case, creating a new directory only
requires only one NFS operation over the wire, and the client is allowed
to keep retrying the operation until it receives a status response from
the server. Retries might be necessary if either the request or the
response packet was dropped by the network, the server crashed, etc.

Momchil Ivanov

unread,
Jul 18, 2007, 7:02:42 PM7/18/07
to
On Wednesday 18 July 2007 21:03:10 Josh Paetzel wrote:
> On Wednesday 18 July 2007, Mark Linimon wrote:
> > On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote:
> > > Bottom line here is that the kernel panics when removing a USB
> > > device that has filesystems mounted.
> >
> > s/USB //
> >
> > > I also have a hard time believing that the reason it hasn't been
> > > fixed is because "there isn't an easy fix". I'm under the
> > > impression it hasn't been fixed because either no one cares
> > > enough to fix it (using the workaround as a scapegoat excuse), or
> > > because the majority of people do not use USB-based storage
> > > devices.
> >
> > The reason is not the USB stack; the reason (IIRC) is that the
> > FreeBSD VM was written with the default assumption that Devices
> > Never Go Away. A large rewrite, I'm told, will be needed to fix
> > this, and the code is convoluted and tricky.
> >
> > No one finds the situation acceptable; introducing the "scapegoat"
> > word isn't going to win you any support. The problem is not a
> > weekend's worth of work to fix, nor does it have anything to do
> > with avoidance by one particular maintainer, which you apparently
> > had encountered before.
> >
> > mcl
>
> Panicing really is the right thing to do with the current
> architecture. Not panicing when a mounted filesystem disappears runs
> the risk of corrupting other mounted filesystems.
>
> Mark is entirely correct, FreeBSD faces an architecture problem here
> in that the vm and filesystems we have today were not designed in an
> era when they could just disappear from a running system. The BSD
> way isn't to apply a quick and dirty little hack to fix
> the 'problem', it's to design the system properly. And this is
> assuming a quick and dirty hack even exists.
>
> The other problem you're running in to with UFS anyways is that there
> is no chance to 'unmount' the filesystem when you disconnect the
> drive. By the time anything has a chance to realize it's gone it's
> too late. Whether the disk is in the middle of a write, still has
> buffers to be written out, or is perfectly clean and needs to just be
> marked as such by the time the OS realizes any of that needs to be
> done the drive is no longer physically connected to the computer.

I think you are missing the point here and it is that the drive is already=
=20
gone, so you do not have to care about it. The state of the drive`s=20
filesystem is of no interest since you cannot to anything to change it any=
=20
more. The point is that the drive is gone. If you were in the middle of a=20
write, you just return an error (like your disk is going physically bad/ so=
me=20
broken cable issue... for instance) and forget about the data you wanted to=
=20
write, the drive is not there any more.=20

Maybe I am naive and uneducated enough (don`t know how freebsd does things,=
=20
nor am I a programmer) but I will give my 2 "stotinki" here.
The most natural way for me seems to be that the OS should just return erro=
rs=20
to the programs trying any I/O on that drive. May be when a drive is=20
unplugged the OS has to mark it and the mounted file systems as not being=20
there until all opened files on it are closed, return errors for all I/O=20
except for closing opened files. And when all files are closed consider the=
=20
fs as unmounted and remove the drive from the kernel.

This is my idea of how things should be done. Ensuring that a file system i=
s=20
in a consistent state after drive disconnect is something completely=20
different (wanted to discuss just disconnecting devices, not filesystems th=
at=20
can be disconnected without unmount, not ensuring fully operational file=20
system even it a case of disconnected drive). One can try to implement=20
something here (as mentioned in some of the replies), but not necessary. If=
=20
the user has unpluged the device without unmounting it first he might be le=
ft=20
with a broken file system on that drive, we cannot do anything, so we shoul=
d=20
not care about it, it`s his mistake and his fs fucked up. The point is that=
=20
unpluging should not lead to system crash, which is in my opinion critical=
=20
system error.

I as user I should be able to unplug any external device without crashing t=
he=20
OS. Doing this and thus leaving me with a broken filesystem or some other=20
device issues should be considered my error. Thus I should learn the hard w=
ay=20
to unmount first.

Designing a filesystem or some hacks to ensure consistent state after=20
disconnect should not be in the scope of this thread and problem, I think.

>
> What might need to happen is a redesign of the vm subsystem so that it

> can safely deal with mounted filesystems going away, and designing a

> filesystem that doesn't need to be unmounted specifically for

> removeable devices. Doesn't sound trivial to me.
>
> Or
>
> You can just not remove devices with mounted filesystems from your

> computer.....

=2D-=20
PGP KeyID: 0x3118168B
Keyserver: pgp.mit.edu
Key fingerprint BB50 2983 0714 36DC D02E =A0158A E03D 56DA 3118 168B
=20

Norberto Meijome

unread,
Jul 18, 2007, 11:15:46 PM7/18/07
to
On Wed, 18 Jul 2007 17:41:04 +0200 (CEST)
Oliver Fromme <ol...@lurza.secnetix.de> wrote:

> If you have problems remembering,

This is very interesting thread indeed....

I have found that mounting remote SMB shares will panic the kernel too, but
only if i try to access it while 'gone' . If I remember correctly, if i thread
carefully around it, i can manage to shutdown everything and it will only panic
at the very last minute when the kernel tries to unmount.

And, from my point of view, the explanation 'well, don't remove your mounted
devices without unmounting them first' is rubbish - the problem is not
necessarily users removing them, but ALL the reasons that could cause an
unwanted and unplanned removal. Like a network outage in the case of smbfs. or
someone killing the power on a USB device. I can't see why the whole kernel
should die on you. Yes, i understand there are architectural reasons for this -
then the architecture is not right anymore, i think.

> another work-around
> is to use the auto mounter daemon (amd(8)). It umounts
> file systems automatically that are not in use.
> Another nice feature of amd(8) is that you don't have
> to mount the file system either -- Simply plug the USB
> stick in, then access it, and amd(8) will automatically
> mount it for you.


Now, something I dont understand - amd runs
at user level, and it mounts filesystems, and nothing dies when the filesystems
go away (other than the obvious cases for the applications trying to write to
the FS in question). Doesn't amd , at some point , have to tell the kernel
'please mount this filesystem' here or there? Isn't the kernel STILL involved
in all this? and why doesnt the kernel panic when the FS goes away?

The same goes for hald - it doesn't work flawlessly, but it does the trick, and
i cant recall an instance when it crashed the kernel.

re. USB disks, could we not by default use amd to mount USB devices? It seems
the obvious native replacement for hald + polkitd + dbus I use in XFCE with
Thunar on my laptop...

TIA!
_________________________
{Beto|Norberto|Numard} Meijome

Never attribute to malice what can adequately be explained by incompetence.

I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.

Norberto Meijome

unread,
Jul 18, 2007, 11:17:12 PM7/18/07
to

Julius Huang

unread,
Jul 19, 2007, 2:42:41 AM7/19/07
to
Hi,

How Mac OS X handle this? Method, tricks, code, etc...

Does Linux reboot when this happen?

One can argue the kernel is so different between OS X, Linux and FBSD,
but it is still better to compare WIN vs FBSD (or NTFS vs UFS).

Or may be I am wrong.

BTW,
I hardly ever put a USB Disk on our FBSD Servers,
but never had problem disconnect USB/Firewire Disk on my Powerbook.

Julius

> To unsubscribe, send any mail to "freebsd-stable-
> unsub...@freebsd.org"

[LoN]Kamikaze

unread,
Jul 19, 2007, 3:03:05 AM7/19/07
to
Oliver Fromme wrote:
> Momchil Ivanov wrote:
> > On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote:
> > > Josh Paetzel wrote:
> > > > Yes, it's expected behavior. The workaround is to not unplug mounted
> > > > devices. (There's nothing special about USB here, if you unplugged an
> > > > IDE drive you'd get the same behavior)
> > >
> > > Wouldn't it make some sense not to panic if mounted devices that are in
> > > sync get removed? A few applications might get in trouble, but that's
> > > hardly a reason to bring a whole system down.
> >
> > I don`t know how things work, but shutting down the system when some
> > mounted fs is no longer present seems like the wrong thing to me.
>
> As Josh wrote, it's expected. The problem is known
> to exist for a long time already (probably as long
> as FreeBSD itself exists), and if there was an easy
> solution, certainly someone would have fixed it.

I remember on 5.3 I removed a mounted USB stick. The system did not panic, all
I had to do was to plug the stick back in to be able to unmount it. So the
behaviour has been more tolerant, in the past.

[LoN]Kamikaze

unread,
Jul 19, 2007, 3:21:02 AM7/19/07
to
Norberto Meijome wrote:
> On Wed, 18 Jul 2007 17:41:04 +0200 (CEST)
> Oliver Fromme <ol...@lurza.secnetix.de> wrote:
>> another work-around
>> is to use the auto mounter daemon (amd(8)). It umounts
>> file systems automatically that are not in use.
>> Another nice feature of amd(8) is that you don't have
>> to mount the file system either -- Simply plug the USB
>> stick in, then access it, and amd(8) will automatically
>> mount it for you.
>
>
> Now, something I dont understand - amd runs
> at user level, and it mounts filesystems, and nothing dies when the filesystems
> go away (other than the obvious cases for the applications trying to write to
> the FS in question). Doesn't amd , at some point , have to tell the kernel
> 'please mount this filesystem' here or there? Isn't the kernel STILL involved
> in all this? and why doesnt the kernel panic when the FS goes away?
>

The trick is that amd unmounts the device after a couple of seconds, so when
someone accidentally removes a usb drive, it doesn't really matter. Amd will
simply fail to mount it on the next access. If you remove the device during or
shortly after accessing it, it still will panic the system.

Momchil Ivanov

unread,
Jul 19, 2007, 3:49:08 AM7/19/07
to
--nextPart2876896.OHRNQ5nC26
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 19 July 2007 09:17:48 [LoN]Kamikaze wrote:
> Norberto Meijome wrote:
> > On Wed, 18 Jul 2007 17:41:04 +0200 (CEST)
> >
> > Oliver Fromme <ol...@lurza.secnetix.de> wrote:
> >> another work-around
> >> is to use the auto mounter daemon (amd(8)). It umounts
> >> file systems automatically that are not in use.
> >> Another nice feature of amd(8) is that you don't have
> >> to mount the file system either -- Simply plug the USB
> >> stick in, then access it, and amd(8) will automatically
> >> mount it for you.
> >
> > Now, something I dont understand - amd runs
> > at user level, and it mounts filesystems, and nothing dies when the
> > filesystems go away (other than the obvious cases for the applications
> > trying to write to the FS in question). Doesn't amd , at some point ,
> > have to tell the kernel 'please mount this filesystem' here or there?
> > Isn't the kernel STILL involved in all this? and why doesnt the kernel
> > panic when the FS goes away?
>
> The trick is that amd unmounts the device after a couple of seconds, so
> when someone accidentally removes a usb drive, it doesn't really matter.
> Amd will simply fail to mount it on the next access. If you remove the
> device during or shortly after accessing it, it still will panic the
> system.

What is then the reason for the kernel not being able to unmount a filesyst=
em=20
whose provider is no longer present? What in the process of unmounting deni=
es=20
unmounting a filesystem whose provider is no longer available? Why can the=
=20
kernel not just inform all programs that files have to be closed and are=20
unaccessible any more, then consider the fs as unmounted and remove any bit=
s=20
of it left in the VM. Why can kernel not just ignore interruped/pending=20
writes to that fs, drop the data, return an error to the program that=20
initiated the write and just go on.

=2D-=20
PGP KeyID: 0x3118168B
Keyserver: pgp.mit.edu

Key fingerprint BB50 2983 0714 36DC D02E =C2=A0158A E03D 56DA 3118 168B
=20

--nextPart2876896.OHRNQ5nC26
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQBGnxYz4D1W2jEYFosRAvuTAKCLCyeWJLbtDM7Dnf3xjTcmeBbBowCePu1o
o65XuPyPWShBfVUZUufODag=
=4XkN
-----END PGP SIGNATURE-----

--nextPart2876896.OHRNQ5nC26--

Julius Huang

unread,
Jul 19, 2007, 4:53:45 AM7/19/07
to

> filesystem


> whose provider is no longer present? What in the process of

> unmounting denies


> unmounting a filesystem whose provider is no longer available? Why
> can the

> kernel not just inform all programs that files have to be closed
> and are

> unaccessible any more, then consider the fs as unmounted and remove

> any bits


> of it left in the VM. Why can kernel not just ignore interruped/
> pending

> writes to that fs, drop the data, return an error to the program that

> initiated the write and just go on.
>

> --

> PGP KeyID: 0x3118168B
> Keyserver: pgp.mit.edu

> Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B
>

Hi,

How Mac OS X handle this? Method, tricks, code, etc...

Does Linux reboot when this happen?

The kernel is different between OS X, Linux and FBSD.

Why FBSD handle this by reboot? Does reboot clean up everything?

BTW,
I hardly ever put a USB Disk on our FBSD Servers,
but never had problem disconnect USB/Firewire Disk on my Powerbook.

Julius

_______________________________________________

Dennis Melentyev

unread,
Jul 19, 2007, 5:24:56 AM7/19/07
to
Hi All!

2007/7/19, Momchil Ivanov <idi...@gmail.com>:

For me, the most expected behaviour of API is the same as socket one:
In case recv/send fails (socket peer gone, router in-the-middle is
died, excavator came across the cables, etc) I just get a timeout (for
the first time), then (once remote socket is considered closed) just
return with -1 and appropriate errno set.
Since every (not braindamaged) program expect possible disk failures,
everyone checks for return/errno. It should be extremely safe to just
supply notify userland with "-1/errno" to handle over the error case
at application level.

Since I do understand the complexity and impact of VM/[V]FS code, I'd
rather vote for funding an external project on better VM/VFS
separation and improvement. Later, this project codebase must be
merged into the CURRENT, tested and go "STABLE" the usual way. The
famous "Floppy" issue of FreeBSD MUST go away, it's just a shame and
long standing base for unpleasant rumor/jokes.

Could it be the good task for FreeBSD Foundation or what ever other investor?
Sorry for adding just 0.02UAH instead of real $20-30-50 of personal
money to the fund's account.
If there is such a fund for this particular problem, I'll vote with
money instead of bytes. I believe, there will be a lot more people
willing to do the same to gain enough funding.

--
Dennis Melentyev

Andriy Gapon

unread,
Jul 19, 2007, 5:41:06 AM7/19/07
to
on 18/07/2007 20:34 Mark Linimon said the following:

> On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote:
>> Bottom line here is that the kernel panics when removing a USB device
>> that has filesystems mounted.
>
> s/USB //
>
>> I also have a hard time believing that the reason it hasn't been fixed
>> is because "there isn't an easy fix". I'm under the impression it
>> hasn't been fixed because either no one cares enough to fix it (using
>> the workaround as a scapegoat excuse), or because the majority of people
>> do not use USB-based storage devices.
>
> The reason is not the USB stack; the reason (IIRC) is that the FreeBSD
> VM was written with the default assumption that Devices Never Go Away.
> A large rewrite, I'm told, will be needed to fix this, and the code is
> convoluted and tricky.
>
> No one finds the situation acceptable; introducing the "scapegoat" word
> isn't going to win you any support. The problem is not a weekend's worth
> of work to fix, nor does it have anything to do with avoidance by one
> particular maintainer, which you apparently had encountered before.

Well, here's my two kopiykas.
Apparently there is somebody who tried to fix this problem, but for some
reason (most probably language barrier) his attempt is largely unnoticed
so far.

Here is a link to a posting to freebsd-fs:
http://lists.freebsd.org/pipermail/freebsd-fs/2007-June/003370.html

Here's a discussion about this patch (in Russian):
http://www.opennet.ru/openforum/vsluhforumID9/6467.html

I have not tried this patch myself.
I am not qualified enough to comment on its quality and the author
admitted that this is more of a workaround or hack rather than perfect
solution.
Also, the patch seems to be msdosfs-centered.

But there are some success reports on the forum mentioned above.
So I thought that this is a good opportunity to draw more attention to
the patch in hope that more people will try it and look at it and
something good will result from it.

--
Andriy Gapon

Andriy Gapon

unread,
Jul 19, 2007, 6:15:12 AM7/19/07
to
on 19/07/2007 13:03 Daniel O'Connor said the following:

> Andriy Gapon wrote:
>> Well, here's my two kopiykas.
>> Apparently there is somebody who tried to fix this problem, but for some
>> reason (most probably language barrier) his attempt is largely unnoticed
>> so far.
>>
>> Here is a link to a posting to freebsd-fs:
>> http://lists.freebsd.org/pipermail/freebsd-fs/2007-June/003370.html
>
> The language barrier won't help, especially since there is no English
> discussion about how the patch works.

Well, barriers usually stop something :-)
There are some comments in Russian, maybe someone will find time to
translate, maybe even me...

> FreeBSD VFS comitters are rare, ones that understand Russian are
> probably almost non-existent :)

There's always a chance.

> Also it would be nice if the patch was a unified diff rather than
> x-patch as that makes it much easier to review.

Patches _are_ unified diffs. The fact that some not-so-smart software
decided that "text/x-patch" is "a non-text attachment" is indeed
inconvenient.

Daniel O'Connor

unread,
Jul 19, 2007, 6:23:18 AM7/19/07
to
Andriy Gapon wrote:
> Well, barriers usually stop something :-)

Heh :)

> There are some comments in Russian, maybe someone will find time to
> translate, maybe even me...

It could come in handy.

>> FreeBSD VFS comitters are rare, ones that understand Russian are
>> probably almost non-existent :)
>
> There's always a chance.

Indeed.

>> Also it would be nice if the patch was a unified diff rather than
>> x-patch as that makes it much easier to review.
>
> Patches _are_ unified diffs. The fact that some not-so-smart software
> decided that "text/x-patch" is "a non-text attachment" is indeed
> inconvenient.

Oops, I am in Windows land at the moment and it mangled them :(

The .bin extension is somewhat confusing as well..

Daniel O'Connor

unread,
Jul 19, 2007, 6:24:07 AM7/19/07
to
Andriy Gapon wrote:
> on 18/07/2007 20:34 Mark Linimon said the following:
>> On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote:
>>> Bottom line here is that the kernel panics when removing a USB device
>>> that has filesystems mounted.
>> s/USB //
>>
>>> I also have a hard time believing that the reason it hasn't been fixed
>>> is because "there isn't an easy fix". I'm under the impression it
>>> hasn't been fixed because either no one cares enough to fix it (using
>>> the workaround as a scapegoat excuse), or because the majority of people
>>> do not use USB-based storage devices.
>> The reason is not the USB stack; the reason (IIRC) is that the FreeBSD
>> VM was written with the default assumption that Devices Never Go Away.
>> A large rewrite, I'm told, will be needed to fix this, and the code is
>> convoluted and tricky.
>>
>> No one finds the situation acceptable; introducing the "scapegoat" word
>> isn't going to win you any support. The problem is not a weekend's worth
>> of work to fix, nor does it have anything to do with avoidance by one
>> particular maintainer, which you apparently had encountered before.
>
> Well, here's my two kopiykas.
> Apparently there is somebody who tried to fix this problem, but for some
> reason (most probably language barrier) his attempt is largely unnoticed
> so far.
>
> Here is a link to a posting to freebsd-fs:
> http://lists.freebsd.org/pipermail/freebsd-fs/2007-June/003370.html

The language barrier won't help, especially since there is no English
discussion about how the patch works.

FreeBSD VFS comitters are rare, ones that understand Russian are
probably almost non-existent :)

Also it would be nice if the patch was a unified diff rather than

x-patch as that makes it much easier to review.

_______________________________________________

Nikola Lecic

unread,
Jul 19, 2007, 7:19:06 AM7/19/07
to
On Thu, 19 Jul 2007 19:49:22 +0930
"Daniel O'Connor" <doco...@gsoft.com.au> wrote:

> Andriy Gapon wrote:
> > Well, barriers usually stop something :-)

>=20
> Heh :)
>=20


> > There are some comments in Russian, maybe someone will find time to
> > translate, maybe even me...

>=20


> It could come in handy.

>=20
> >> FreeBSD VFS comitters are rare, ones that understand Russian are=20
> >> probably almost non-existent :)
> >=20


> > There's always a chance.

>=20
> Indeed.

http://translate.google.com/translate?u=3Dhttp%3A%2F%2Fwww.opennet.ru%2Fope=
nforum%2FvsluhforumID9%2F6467.html&langpair=3Dru%7Cen&hl=3Den&ie=3DUTF8

Useful? Seems comprehensible enough (maybe a wrong impression since I
understand Russian text).

Nikola Le=C4=8Di=C4=87

Peter Jeremy

unread,
Jul 19, 2007, 7:25:34 AM7/19/07
to

--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-Jul-19 00:57:57 +0200, Momchil Ivanov <idi...@gmail.com> wrote:
>I think you are missing the point here and it is that the drive is already=
=20
>gone, so you do not have to care about it.

I don't think anyone is missing this point.

>The most natural way for me seems to be that the OS should just return err=
ors=20


>to the programs trying any I/O on that drive. May be when a drive is=20
>unplugged the OS has to mark it and the mounted file systems as not being=
=20
>there until all opened files on it are closed, return errors for all I/O=
=20

>except for closing opened files. And when all files are closed consider th=
e=20


>fs as unmounted and remove the drive from the kernel.

And everyone I am aware of agrees that this is what _should_ happen.
Unfortunately, as has already been mentioned, the filesystem and VM
code have a very incestuous relationship and actually _making_ FreeBSD
behave this way is (from all accounts) very difficult. There is
already an entry on the project ideas list to at least make this work
for MSDOSFS (http://www.freebsd.org/projects/ideas/#p-msdosfs - also
part of SOC2007).

>This is my idea of how things should be done. Ensuring that a file system =
is=20


>in a consistent state after drive disconnect is something completely=20
>different

Note that UFS+softupdates already implements this.

--=20
Peter Jeremy

--z6Eq5LdranGa6ru8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFGn0lm/opHv/APuIcRAsqgAKClNdYxduvIIPIC7YE4TyswIq2erwCfYGSJ
OEx3hqqnowglb89pO03fXV4=
=HMoy
-----END PGP SIGNATURE-----

--z6Eq5LdranGa6ru8--

Peter Jeremy

unread,
Jul 19, 2007, 7:27:18 AM7/19/07
to

--L6iaP+gRLNZHKoI4

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-Jul-19 08:58:27 +0200, "[LoN]Kamikaze" <LoN_Ka...@gmx.de> wrote:
>I remember on 5.3 I removed a mounted USB stick. The system did not panic,=


all
>I had to do was to plug the stick back in to be able to unmount it. So the
>behaviour has been more tolerant, in the past.

Did you or the syncer thread try to write to the stick whilst it was
absent? If not then the OS would have been unaware of its absence.

--=20
Peter Jeremy

--L6iaP+gRLNZHKoI4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFGn0ni/opHv/APuIcRAgUaAJ9c+LzI1iwd6ifFQ/Lel4iTLSPB1ACdGBih
MZ5nCnmlYUR6AivW7Wnoqk8=
=6Vji
-----END PGP SIGNATURE-----

--L6iaP+gRLNZHKoI4--

M. Warner Losh

unread,
Jul 19, 2007, 10:46:57 AM7/19/07
to
In message: <469E1B2A...@gmx.de>
"[LoN]Kamikaze" <LoN_Ka...@gmx.de> writes:
: Josh Paetzel wrote:
: > On Wednesday 18 July 2007, Momchil Ivanov wrote:
: >> Hi,
: >>
: >> I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007
: >> and accidently unplugged the USB hub to which my external hdd
: >> together with a mouse were connected and this caused my machine to
: >> freeze for some seconds and then reboot. At that moment the hdd was
: >> mounted and I was playing music out of it.
: >> After that I tried to reproduce it :) so just plugged only the hdd
: >> directly, mounted it and started playing music files from it. When
: >> I unplugged the USB cable the same thing happened: short freeze,
: >> and then reboot. Is this expected behaviour? And is there some way
: >> to avoid the freeze and reboot?
: >>
: >> Thanks.
: >
: > Yes, it's expected behavior. The workaround is to not unplug mounted
: > devices. (There's nothing special about USB here, if you unplugged an
: > IDE drive you'd get the same behavior)
: >
:
: Wouldn't it make some sense not to panic if mounted devices that are in sync
: get removed? A few applications might get in trouble, but that's hardly a
: reason to bring a whole system down.

This is this week's winner in the Zen Master of the Obvious award.

Yes. It is a known problem that should be fixed.

Warner

M. Warner Losh

unread,
Jul 19, 2007, 10:55:00 AM7/19/07
to
In message: <20070718170...@eos.sc1.parodius.com>
Jeremy Chadwick <koi...@freebsd.org> writes:
: If someone wants to work on this and needs devices/toys (thumb drives,
: external enclosures + hard disks), let me know, I will be more than
: happy to buy them the hardware needed.

Willing to fund the work on it too? This is a volunteer project, and
you have to motivate people to work on this. Tirades in mailing lists
has proven to be ineffective in the past.

I've looked at the issue, and generically, if a device goes away, it
is *HARD* to not panic. The same thing happens if you eject a CF card
in a PC Card adapter in a PC Card slot.

The best one can do without massive buffer cache work is what firewire
does: it has one attachment to handle all umass devices. When the
device goes away, it pauses all operations to that device. If the
device comes back, it resumes the I/O . If the device never comes
back, then the I/O never finishes.

M. Warner Losh

unread,
Jul 19, 2007, 11:00:28 AM7/19/07
to
In message: <200707181942....@gmail.com>
Momchil Ivanov <idi...@gmail.com> writes:
: On Wednesday 18 July 2007 19:34:06 Mark Linimon wrote:

: > On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote:
: > > Bottom line here is that the kernel panics when removing a USB device
: > > that has filesystems mounted.
: >
: > s/USB //
:
: Just a dumb question: what does "umount -f" does? And doing something like
: that when a fs goes away shouldn`t fix it?

It won't fix it. The problem is dangling pointers to devices that no
longer exist. And like all dangling references after 'free' you get
bad thing happening.

: If the problem is in general with a file system, regardless of the provider,

: then what does one do when a mounted smbfs becomes unavailable due to remote
: host down, no route to host or some other network related problems? Same
: question for NFS mounted filesystems?

In those cases, the device doesn't go away. Just the remote host.
This is a big difference.

Believe me, if it were easy, it would have been fixed. If it was
moderate to fix, it would have been fixed. It is a hard problem that
people have put lots of hours into to try to resolve. To imply
otherwise is really insulting to all those people (myself include)
that have tried to fix this.

M. Warner Losh

unread,
Jul 19, 2007, 11:05:50 AM7/19/07
to
In message: <20070718200...@eos.sc1.parodius.com>
Jeremy Chadwick <koi...@freebsd.org> writes:
: This would alleviate concerns over data loss, would it not?

No. The problem is more basic: the device *driver* is gone. All the
code unwinding has happened. The physical device is also gone, which
is what triggered the detach. Doing synchronous writes wouldn't
help. The next time the file system was touched, it would dereference
a device that no longer exists, giving random results, in this case a
crash.

Meaning no disrespect for enthusiastic users, I really wish that
people with "suggestions" would actually try to fix it themselves
before making such obviously wrong comments. I have the right to say
this because I have tried to fix this, and have run into these issues.

Like I've said before, if it were easy, one of the dozen or so people
that have tried to fix it in the past 8 years would have succeeded.

Jeremy Chadwick

unread,
Jul 19, 2007, 11:09:13 AM7/19/07
to
On Thu, Jul 19, 2007 at 08:48:21AM -0600, M. Warner Losh wrote:
> In message: <20070718170...@eos.sc1.parodius.com>
> Jeremy Chadwick <koi...@freebsd.org> writes:
> : If someone wants to work on this and needs devices/toys (thumb drives,
> : external enclosures + hard disks), let me know, I will be more than
> : happy to buy them the hardware needed.
>
> Willing to fund the work on it too? This is a volunteer project, and
> you have to motivate people to work on this.

I'm one man with a single day job. I only make so much money a year,
most of which goes to rent and co-location bills. Remaining amounts
usually go to small hobby projects of mine, or donating money to folks
like phk@ to work on features that I'll benefit from (serial console
work comes to mind, ditto with BTX fixes).

What I'm saying is that I can't afford (literally -- I don't have the
cash) to pay someone US$40/hour for programming efforts (especially when
I know it'd be a 8-12 week job), but I *can* afford to donate a few
hundred bucks getting someone hardware who has the know-how to fix or
test things much better than myself. Most of the time though I'm told
"I have the hardware I need -- it's a matter of finding the time!"

Ain't that the truth. :-)

Besides working on ports (which I've been slacking on as of late), this
is how I try to help/contribute to the FreeBSD community.

> The best one can do without massive buffer cache work is what firewire
> does: it has one attachment to handle all umass devices. When the
> device goes away, it pauses all operations to that device. If the
> device comes back, it resumes the I/O . If the device never comes
> back, then the I/O never finishes.

This sounds good.

--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |

M. Warner Losh

unread,
Jul 19, 2007, 11:15:30 AM7/19/07
to
In message: <469F0B93...@gmx.de>
"[LoN]Kamikaze" <LoN_Ka...@gmx.de> writes:

: Oliver Fromme wrote:
: > Momchil Ivanov wrote:
: > > On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote:
: > > > Josh Paetzel wrote:
: > > > > Yes, it's expected behavior. The workaround is to not unplug mounted
: > > > > devices. (There's nothing special about USB here, if you unplugged an
: > > > > IDE drive you'd get the same behavior)
: > > >
: > > > Wouldn't it make some sense not to panic if mounted devices that are in
: > > > sync get removed? A few applications might get in trouble, but that's
: > > > hardly a reason to bring a whole system down.
: > >
: > > I don`t know how things work, but shutting down the system when some

: > > mounted fs is no longer present seems like the wrong thing to me.
: >
: > As Josh wrote, it's expected. The problem is known
: > to exist for a long time already (probably as long
: > as FreeBSD itself exists), and if there was an easy
: > solution, certainly someone would have fixed it.
:
: I remember on 5.3 I removed a mounted USB stick. The system did not panic, all

: I had to do was to plug the stick back in to be able to unmount it. So the
: behaviour has been more tolerant, in the past.

I'm pretty sure that 5.3 panics when you do this. At least my 5.3
machine at work did last time I tried it, which was just last week.

Warner

M. Warner Losh

unread,
Jul 19, 2007, 11:19:36 AM7/19/07
to
In message: <200707190943....@gmail.com>
Momchil Ivanov <idi...@gmail.com> writes:
: What is then the reason for the kernel not being able to unmount a

: filesystem whose provider is no longer present?

The problem is that the device driver has wound down, deallocated
memory, etc. Now the kernel comes along with stale references to the
device and panic ensues. It is really just that simple. There's no
replacement of the now-dead device with dead calls.

And even if you fixed that, most of the file systems in the tree today
do not tolerate errors on writes at all and that also leads to
panics. This is why firewire freezes the I/Os rather than failing
them (and why umount -f on a firewire drive hangs).

[LoN]Kamikaze

unread,
Jul 19, 2007, 11:42:18 AM7/19/07
to
M. Warner Losh wrote:
> In message: <20070718145...@gremlin.foo.is>
> Baldur Gislason <bal...@foo.is> writes:
> : I vaguely remember being able to yank out USB drives in 5.x and just make
> : usbd execute a forced umount without any problems. FAT32 drives mind you.
> : On 6.2 I haven't even been able to unplug a USB drive even if I unmount it
> : first, always results in a kernel panic.
>
> This has never worked. Not even on 5.x. Or 4.10. I've tested these
> both recently accidentally...
>
> Warner

As I mentioned earlier I remember it working during the 5.3 era on Stable, at
some point it worked. I even remember removing my CD-Rom drive from my Thinkpad
without running atacontrol detach. The system just took it and the drive just
continued working after I put it back in.

Anyway, is there a way to convince the kernel that removable devices are NFS
mounts? I suppose there'd be an additional layer required that clusters file
operations to consistent atomic operations similar to NFS.

Josh Paetzel

unread,
Jul 19, 2007, 12:43:51 PM7/19/07
to
--nextPart4576160.1lHOmQfbd2
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 19 July 2007, M. Warner Losh wrote:
> In message: <20070718170...@eos.sc1.parodius.com>
>
> Jeremy Chadwick <koi...@freebsd.org> writes:
> : If someone wants to work on this and needs devices/toys (thumb
> : drives, external enclosures + hard disks), let me know, I will be
> : more than happy to buy them the hardware needed.
>
> Willing to fund the work on it too? This is a volunteer project,

> and you have to motivate people to work on this. Tirades in


> mailing lists has proven to be ineffective in the past.
>
> I've looked at the issue, and generically, if a device goes away,
> it is *HARD* to not panic. The same thing happens if you eject a
> CF card in a PC Card adapter in a PC Card slot.
>

> The best one can do without massive buffer cache work is what

> firewire does: it has one attachment to handle all umass devices.=20


> When the device goes away, it pauses all operations to that device.
> If the device comes back, it resumes the I/O . If the device
> never comes back, then the I/O never finishes.
>

> Warner
>

Just curious, but what, if any, is the performance hit with this=20
strategy? I could care less about performance on a usb stick, but if=20
we are talking about changes that are going to affect all filesystems=20
regardless of storage device implimentation then I'm sort of=20
interested.

eg: I wouldn't be happy trading filesystem performance for avoiding a=20
panic that is trivial to avoid in the first place.

=2D-=20
Thanks,

Josh Paetzel

--nextPart4576160.1lHOmQfbd2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQBGn5OyJvkB8SevrssRAsqXAJ98RETmGzxIBmt2SiBB5zt0S3dnSACfXHkp
ci5jccivyKEhONXAHppH+4Y=
=bgmg
-----END PGP SIGNATURE-----

--nextPart4576160.1lHOmQfbd2--

Ian Smith

unread,
Jul 19, 2007, 1:17:55 PM7/19/07
to
On Thu, 19 Jul 2007, M. Warner Losh wrote:
> In message: <469F0B93...@gmx.de>
> "[LoN]Kamikaze" <LoN_Ka...@gmx.de> writes:
> : Oliver Fromme wrote:
> : > Momchil Ivanov wrote:
> : > > On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote:
> : > > > Josh Paetzel wrote:
> : > > > > Yes, it's expected behavior. The workaround is to not unplug mounted
> : > > > > devices. (There's nothing special about USB here, if you unplugged an
> : > > > > IDE drive you'd get the same behavior)
> : > > >
> : > > > Wouldn't it make some sense not to panic if mounted devices that are in
> : > > > sync get removed? A few applications might get in trouble, but that's
> : > > > hardly a reason to bring a whole system down.
> : > >
> : > > I don`t know how things work, but shutting down the system when some
> : > > mounted fs is no longer present seems like the wrong thing to me.
> : >
> : > As Josh wrote, it's expected. The problem is known
> : > to exist for a long time already (probably as long
> : > as FreeBSD itself exists), and if there was an easy
> : > solution, certainly someone would have fixed it.
> :
> : I remember on 5.3 I removed a mounted USB stick. The system did not panic, all
> : I had to do was to plug the stick back in to be able to unmount it. So the
> : behaviour has been more tolerant, in the past.
>
> I'm pretty sure that 5.3 panics when you do this. At least my 5.3
> machine at work did last time I tried it, which was just last week.

5.4 too. Now at 5.5-STABLE, on APM if it matters, I've had much fun
several times having the laptop, when on battery, suspend/resume with a
USB stick mounted on da0 (msdosfs or ufs) - without removing the device.

With rc.suspend kldunload'ing usb and rc.resume kldload'ing it (as
recommended for UHCI and, iirc, needed here) then on resume umass0
detaches & reattaches, but assigns the stick to da1. mount still shows
the da0sX mount. It doesn't panic unless / until something accesses
da0. So at least I usually get a window to reboot, the only way out.

Sure I've learned "don't do that" but it's painful when I forget ..

Might this new USB stack offer any relief to this need to unload/reload
usb on s/r, and if so keep hold of a mount (assuming the stick remains)?

Cheers, Ian

M. Warner Losh

unread,
Jul 19, 2007, 11:31:33 PM7/19/07
to
In message: <20070719145...@eos.sc1.parodius.com>
Jeremy Chadwick <koi...@FreeBSD.org> writes:
: On Thu, Jul 19, 2007 at 08:48:21AM -0600, M. Warner Losh wrote:
: > In message: <20070718170...@eos.sc1.parodius.com>

: > Jeremy Chadwick <koi...@freebsd.org> writes:
: > : If someone wants to work on this and needs devices/toys (thumb drives,
: > : external enclosures + hard disks), let me know, I will be more than
: > : happy to buy them the hardware needed.
: >
: > Willing to fund the work on it too? This is a volunteer project, and
: > you have to motivate people to work on this.
:
: I'm one man with a single day job. I only make so much money a year,

: most of which goes to rent and co-location bills. Remaining amounts
: usually go to small hobby projects of mine, or donating money to folks
: like phk@ to work on features that I'll benefit from (serial console
: work comes to mind, ditto with BTX fixes).
:
: What I'm saying is that I can't afford (literally -- I don't have the
: cash) to pay someone US$40/hour for programming efforts (especially when
: I know it'd be a 8-12 week job), but I *can* afford to donate a few
: hundred bucks getting someone hardware who has the know-how to fix or
: test things much better than myself. Most of the time though I'm told
: "I have the hardware I need -- it's a matter of finding the time!"

A total fix would be a lot of effort. Some of it would be easy to
incrementally adopt, while other parts would have ripples far and
wide.

: Besides working on ports (which I've been slacking on as of late), this


: is how I try to help/contribute to the FreeBSD community.

Yea. I understand that.

: > The best one can do without massive buffer cache work is what firewire
: > does: it has one attachment to handle all umass devices. When the


: > device goes away, it pauses all operations to that device. If the
: > device comes back, it resumes the I/O . If the device never comes
: > back, then the I/O never finishes.

:
: This sounds good.

It likely is the easiest 'bang for buck' solution.

Warner

Christian Walther

unread,
Jul 20, 2007, 2:44:21 AM7/20/07
to
On 19/07/07, M. Warner Losh <i...@bsdimp.com> wrote:
[...]

>
> The best one can do without massive buffer cache work is what firewire
> does: it has one attachment to handle all umass devices. When the
> device goes away, it pauses all operations to that device. If the
> device comes back, it resumes the I/O . If the device never comes
> back, then the I/O never finishes.
>
Is this safe? I don't know where locking occurs in this case, but if
locking occurs on a very low level it's potentially dangerous. If a
device is removed (either on purpose or by accident) the kernel can't
determine the state of the filesystem anymore.
So the user could plug the device into another machine, start some
write operations on the device, and put it back into the FreeBSD
machine.
This wouldn't know anything about the changes done, and just flush its
buffer, probably using blocks that have been filled previously.

It's a pity that FreeBSD can't handle these situations.
Since no one here on this list has enough money to get development on
the road, maybe we could try collecting money? Everyone interested in
seeing this issue fixed offers the amount of money he/she likes to
spend...

I guess for a "Summer of Code" project this issue would be to big to
fix, wouldn't it?

David Schwartz

unread,
Jul 20, 2007, 6:28:44 PM7/20/07
to

> It won't fix it. The problem is dangling pointers to devices that no
> longer exist. And like all dangling references after 'free' you get
> bad thing happening.

> Believe me, if it were easy, it would have been fixed. If it was


> moderate to fix, it would have been fixed. It is a hard problem that
> people have put lots of hours into to try to resolve. To imply
> otherwise is really insulting to all those people (myself include)

> that have tried to fix this.

There is a simple but ugly way to fix it, similar to what the FireWire layer
does. The idea is for the USB layer to create a "device that never goes
away" when it first sees the stick and pass that "device that never goes
away" to the other layers. Even if the storage device is removed, the device
still does not go away.

The virtual device can generate errors if the physical device is missing.
The virtual device can be cleaned up when the device is unmounted. This will
ensure that the 'umount -f' process generates errors (which it will ignore)
rather than crashes (which are somewhat harder to ignore).

DS

Matthias Schuendehuette

unread,
Jul 20, 2007, 7:01:44 PM7/20/07
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Am 20.07.2007 um 08:16 schrieb Christian Walther:

> [...]


> It's a pity that FreeBSD can't handle these situations.
> Since no one here on this list has enough money to get development on
> the road, maybe we could try collecting money? Everyone interested in
> seeing this issue fixed offers the amount of money he/she likes to
> spend...
>
> I guess for a "Summer of Code" project this issue would be to big to
> fix, wouldn't it?

Especially if I think about software RAID it's really a show-stopper.
I remember a stress-test of *vinum* (without the "g") years ago when
I pulled the plug on one of the disks of a RAID5-plex...

Obviously there's no change at all concerning this problem.

- --
Ciao/BSD - Matthias

Matthias Schuendehuette <msch [at] snafu.de>, Berlin (Germany)
PGP-Key at <pgp.mit.edu> and <wwwkeys.de.pgp.net> ID: 0xDDFB0A5F

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFGoTatf1BNcN37Cl8RAmTRAJ99PXwWaHxUq4I8P++hcMhpL5PSlwCgg5/R
9gy1Gj2+JYTRB5OvGOWFDF4=
=XVsv
-----END PGP SIGNATURE-----

Norberto Meijome

unread,
Jul 20, 2007, 9:03:54 PM7/20/07
to
On Thu, 19 Jul 2007 17:38:14 +0200
"[LoN]Kamikaze" <LoN_Ka...@gmx.de> wrote:

> As I mentioned earlier I remember it working during the 5.3 era on Stable, at
> some point it worked. I even remember removing my CD-Rom drive from my Thinkpad
> without running atacontrol detach. The system just took it and the drive just
> continued working after I put it back in.

on 6.2-STABLE (of a few days ago), i have this happening a couple of times with no adverse effect at all.
Burn DVD/Cd, when finished, hald detects the disk, mounts it, /dev/cd0 in /media/whatever.

i can eject the disk just fine (which in itself is weird, i think).... the device is still there...
umount /dev/cd0

works fine and off it goes. other than that, no, i havent tried to access the device in question

_________________________
{Beto|Norberto|Numard} Meijome

"The people have always some champion whom they set over them and nurse into greatness...
This and no other is the root from which a tyrant springs; when he first appears he is a protector."
Plato

I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned.

Norberto Meijome

unread,
Jul 20, 2007, 9:09:21 PM7/20/07
to
On Thu, 19 Jul 2007 09:02:50 -0600 (MDT)

"M. Warner Losh" <i...@bsdimp.com> wrote:

> In message: <200707190943....@gmail.com>
> Momchil Ivanov <idi...@gmail.com> writes:
> : What is then the reason for the kernel not being able to unmount a
> : filesystem whose provider is no longer present?
>
> The problem is that the device driver has wound down, deallocated
> memory, etc. Now the kernel comes along with stale references to the
> device and panic ensues. It is really just that simple. There's no
> replacement of the now-dead device with dead calls.
>
> And even if you fixed that, most of the file systems in the tree today
> do not tolerate errors on writes at all and that also leads to
> panics. This is why firewire freezes the I/Os rather than failing
> them (and why umount -f on a firewire drive hangs).

Please point me to the correct RTFM, because I feel this worth it :)

Is there a reason why the kernel cannot check 'upwards' if a device is being used, ie mounted ? and prevent the unloading of the device driver ?

thanks for your time illuminating this ignoramus :)

_________________________
{Beto|Norberto|Numard} Meijome

"Egotism is the anesthetic that dulls the pain of stupidity."
Frank Leahy

Stefan Esser

unread,
Jul 21, 2007, 11:36:18 AM7/21/07