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
>
next prev parent 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®