public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: graceful handling of removing a plugable storage device that is being written to
Date: Sun, 11 Sep 2011 12:08:25 +0200	[thread overview]
Message-ID: <201109111208.25761.Martin@lichtvoll.de> (raw)

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.

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

             reply	other threads:[~2011-09-11 10:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-11 10:08 Martin Steigerwald [this message]
2011-09-11 14:31 ` graceful handling of removing a plugable storage device that is being written to Hin-Tak Leung
2011-09-11 16:53   ` Martin Steigerwald
2011-09-11 19:01     ` Geert Uytterhoeven
2011-09-11 19:06       ` Martin Steigerwald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201109111208.25761.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox