From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Steigerwald Subject: How to handle remove media (was: Re: What about not warn on some abort_transaction() case whose reason is known?) Date: Wed, 31 Dec 2014 11:24:32 +0100 Message-ID: <1433170.itgjFWUuZD@merkaba> References: <54A351C9.7070504@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-btrfs , linux-fsdevel@vger.kernel.org To: Qu Wenruo Return-path: Received: from mondschein.lichtvoll.de ([194.150.191.11]:45030 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751608AbaLaKYg convert rfc822-to-8bit (ORCPT ); Wed, 31 Dec 2014 05:24:36 -0500 In-Reply-To: <54A351C9.7070504@cn.fujitsu.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: I am cc=C2=B4ing this to fsdevel as I think how to handle a disconnecte= d usb device=20 may be of broader interest. Well free to drop Cc again in case you see = it as=20 only BTRFS specific issue. Am Mittwoch, 31. Dezember 2014, 09:30:49 schrieb Qu Wenruo: > Hi all, Hi Qu, > While surfing the Redhat BZ, a lot(at least 5 I found in one month)=20 > users report "bugs" in btrfs about > kernel warning in btrfs_abort_transaction(). > And most of them (about 3 or more) are caused by disconnected usb dev= ice. >=20 > So I'm considering not to warn on some cases if we know its reason, l= ike=20 > the above device disconnected > case, but still warn on other cases. > This should reduce many unneeded bug report for the usb disconnected = case. >=20 > Any advice is welcomed. How about warning, but also mentioned the *reason*? Disconnecting an USB device without unmounting is still not so nice and= a=20 warning, well, any unwritten data has been lost then already, so, but s= till. I=20 know with esata disks you have a grace time, if you replug it quickly e= nough=20 while libata driver is still retrying it will continue the write. I for a long time thought about a feature request for the Linux kernel = to=20 handle removable media in the very sane way AmigaOS does. I never did s= o in=20 all the years, but heck, why not today? If you remove it while writing, you get a nice dialog saying "You MUST insert volume xyz again" You do it, and it continues writing. Now how cute is that? Its the best= way to=20 handle this kind of situation for the user in my point of view. (On the= other=20 hand, if you didn=C2=B4t, and it was a floppy disk with original Amiga = filesystem,=20 the disk was broke, so the "MUST" was no joke). I remember that this has been topic of a summer of code project for Net= BSD,=20 but I don=C2=B4t know what came out of it. I know the difficulties with this. The kernel will need to pile up I/O = to the=20 device and at some point halt processes to prevent memory exhaustion. A= nd then=20 you need to route the request to reinsert the medium to the user, to th= e=20 desktop. And what do you do on a server? Where do you ask then? On the = command=20 line? And if so, how do to that in a non annoying way? Maybe that is ju= st=20 something to opt in for a desktop system. So this would be quite some work, but I always thought: How AmigaOS han= dles=20 this is the *only* sane way to do it for any media that you cannot prev= ent=20 accidental removal on a hardware level =E2=80=93 at least for the deskt= op case. At=20 least from a users point of view. Just discarding data on that accident= is=20 just plain unfriendly to the user and an invitation for data loss (if t= he user=20 chose to move files instead of copying them). And I found it that for some users I can tell them to safely remove the= USB=20 stick before unplugging it again and again, but they still won=C2=B4t d= o it, it=20 just doesn=C2=B4t sink in. Meanwhile I usually say: Wait 30 seconds aft= er last=20 write and then unplug and then hope for the best. I still think AmigaOS goes beyond all the other operation systems I kno= w with=20 this feature. But well, I am not exactly sure how MS-DOS or Windows han= dle=20 this. I vaguely remember some retry prompt from MS-DOS, but it may have= been=20 for another case. But well, so yes, a warning in the log may just be completely useless, = cause=20 its too late then, for the data that was about to be safed. And if ther= e is no=20 data to be saved anymore, a warning does not make any sense either, cau= se=20 there isn=C2=B4t a problem. Yet, an aborted transaction means there was= data to be=20 saved, so. So or so, this may be something to handle on the block or VFS layer any= way? Ciao, --=20 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