Message-ID: <1315751507.52552.YahooMailClassic@web29517.mail.ird.yahoo.com>
Date:	Sun, 11 Sep 2011 15:31:47 +0100 (BST)
From:	Hin-Tak Leung <hintak_leung@...oo.co.uk>
To:	linux-fsdevel@...r.kernel.org,
	Martin Steigerwald <Martin@...htvoll.de>
Cc:	linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org
Subject: Re: graceful handling of removing a plugable storage device that is being written to

--- On Sun, 11/9/11, Martin Steigerwald <Martin@...htvoll.de> wrote:

> Cc to BTRFS mailinglist as it
> triggered the idea of mine again.
> 
> 
> Hi!
> 
> Today I did it again and removed a BTRFS partition that is
> written too. 
> That BTRFS as of Kernel 3.0.3 (debian package) does not
> like very much. I 
> think thats a known issue and I wrote a mail to BTRFS
> mailing list about 
> it.
> 
> In there I wrote:
> 
> > Expected results:
> > 
> > BTRFS fails gracefully except the loss of data from
> writes in flight, the 
> > machine remains usable and BTRFS can be mounted
> again.
> 
> And then cause the expected results IMHO are by no way the
> ideal results:
> 
> 
> > Ideal results (IMHO):
> > 
> > Linux behaved like AmigaOS and told me that I *must*
> insert the device 
> > again and *continues* writing after I did this. 
> 
> But I never saw any other OS that did that.
> 
> And I see the problems with high bandwidth writes piling up
> in memory 
> causing severe memory pressure.
> 
> But then could Linux just freeze processes that continue
> writing to the 
> drive until it is replugged again? Of course that
> shouldn´t happen to the 
> drive / resides on.
> 
> And there is a userspace part in it - the possibly udev and
> dbus  driven 
> notification to the user.

How do you cope with 
(1) headless systems (one where there is no udev/dbus notification or display).
(2) the user walking off in a hurry and never seeing the notification?
Should the kernel/user processes freeze indefinitely?

There is also a 3rd scenario - how how one malicious person or process doing a repeat insert/remove/write and get resource to pile up and crash the machine?

It is probably possible/recommended with Amiga because Amiga is seldomly run headless?

> 
> Yet despite all of this NetBSD has a gsoc 2011 project at
> least suggested 
> for exactly this behavior:
> 
> Graceful USB disk detach/reattach
> http://wiki.netbsd.org/projects/gsoc_2011/disk-removal/
> 
> They even mention the Amiga in there.
> 
> Okay, its only for USB, not for eSATA, but I think it
> should be made 
> generic for removable devices.
> 
> Would that be possible? I gladly file an enhancement
> request about it or 
> help testing it.
> 
> I think thats the only approach that makes sense here. USB
> sticks and 
> harddisks have no means to disallow device removal at any
> time. Thus the 
> OS should offer the user a way to rethink the decision and
> plug the device 
> in to prevent data loss. Actually I am surprised that no
> other operating 
> system except AmigaOS seemed to offer this behavior. Well I
> am not quite 
> sure about MS-DOS writing to disk. Maybe it even did that.
> But I did not 
> use MS-DOS often. 
> 
> All current mainstream operating systems I know of default
> to loose data 
> in that case. I think there is a better choice. What do you
> think? Might 
> not be much of a server feature, but important for the
> desktop.
> 
> Ciao,
> -- 
> Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
> GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599
> 84C7
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists