Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Jul 2007 08:16:11 +0200
From:      "Christian Walther" <cptsalek@gmail.com>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: removing external usb hdd without unmounting causes reboot?
Message-ID:  <14989d6e0707192316p4bd1393dj1c9f73ea0686e40@mail.gmail.com>
In-Reply-To: <20070719.084821.-202614780.imp@bsdimp.com>
References:  <200707181541.l6IFf4ht051775@lurza.secnetix.de> <200707181830.48727.idiotbg@gmail.com> <20070718170559.GA11915@eos.sc1.parodius.com> <20070719.084821.-202614780.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 19/07/07, M. Warner Losh <imp@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?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14989d6e0707192316p4bd1393dj1c9f73ea0686e40>