mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hin-Tak Leung <hintak_leung@yahoo.co.uk>
To: linux-fsdevel@vger.kernel.org, Martin Steigerwald <Martin@lichtvoll.de>
Cc: linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: graceful handling of removing a plugable storage device that is being written to
Date: Sun, 11 Sep 2011 15:31:47 +0100 (BST)	[thread overview]
Message-ID: <1315751507.52552.YahooMailClassic@web29517.mail.ird.yahoo.com> (raw)
In-Reply-To: <201109111208.25761.Martin@lichtvoll.de>

--- On Sun, 11/9/11, Martin Steigerwald <Martin@lichtvoll.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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2011-09-11 14:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-11 10:08 Martin Steigerwald
2011-09-11 14:31 ` Hin-Tak Leung [this message]
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=1315751507.52552.YahooMailClassic@web29517.mail.ird.yahoo.com \
    --to=hintak_leung@yahoo.co.uk \
    --cc=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

all inboxes | Powered by JetHome®