From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qu Wenruo Subject: Re: How to handle remove media Date: Fri, 2 Jan 2015 09:22:35 +0800 Message-ID: <54A5F2DB.9040009@cn.fujitsu.com> References: <54A351C9.7070504@cn.fujitsu.com> <1433170.itgjFWUuZD@merkaba> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-btrfs , To: Martin Steigerwald Return-path: In-Reply-To: <1433170.itgjFWUuZD@merkaba> Sender: linux-btrfs-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org -------- Original Message -------- Subject: How to handle remove media (was: Re: What about not warn on=20 some abort_transaction() case whose reason is known?) =46rom: Martin Steigerwald To: Qu Wenruo Date: 2014=E5=B9=B412=E6=9C=8831=E6=97=A5 18:24 > I am cc=C2=B4ing this to fsdevel as I think how to handle a disconnec= ted usb device > may be of broader interest. Well free to drop Cc again in case you se= e it as > 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) >> 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 de= vice. >> >> So I'm considering not to warn on some cases if we know its reason, = like >> the above device disconnected >> case, but still warn on other cases. >> This should reduce many unneeded bug report for the usb disconnected= case. >> >> Any advice is welcomed. > How about warning, but also mentioned the *reason*? > > Disconnecting an USB device without unmounting is still not so nice a= nd a > warning, well, any unwritten data has been lost then already, so, but= still. I > know with esata disks you have a grace time, if you replug it quickly= enough > while libata driver is still retrying it will continue the write. Unneeded kernel warning always leads to duplicated BZ, but on the other= =20 hand, it's true that is a problem and need to warn user. So warning with reason seems good enough. > > > I for a long time thought about a feature request for the Linux kerne= l to > handle removable media in the very sane way AmigaOS does. I never did= so in > 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 be= st way to > handle this kind of situation for the user in my point of view. (On t= he other > hand, if you didn=C2=B4t, and it was a floppy disk with original Amig= a filesystem, > the disk was broke, so the "MUST" was no joke). > > I remember that this has been topic of a summer of code project for N= etBSD, > 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 > device and at some point halt processes to prevent memory exhaustion.= And then > you need to route the request to reinsert the medium to the user, to = the > desktop. And what do you do on a server? Where do you ask then? On th= e command > line? And if so, how do to that in a non annoying way? Maybe that is = just > something to opt in for a desktop system. Other than the method to inform users, more difficulties lie in the=20 half-written handle things, filesystems may need to keep all the page caches even after some of them is written to disk,= =20 to ensure they can be re-queued to handle disk remove. This may need to a huge change to almost every fs to implement a full=20 rollback(at least full rollback to previous version) transaction mechanism(good news is, btrfs may be less impacted), and th= e=20 problem you already mentioned, extra memory usage. But the idea is still great, I really hope to see it. Thanks, Qu > > So this would be quite some work, but I always thought: How AmigaOS h= andles > this is the *only* sane way to do it for any media that you cannot pr= event > accidental removal on a hardware level =E2=80=93 at least for the des= ktop case. At > least from a users point of view. Just discarding data on that accide= nt is > just plain unfriendly to the user and an invitation for data loss (if= the user > chose to move files instead of copying them). > > And I found it that for some users I can tell them to safely remove t= he USB > stick before unplugging it again and again, but they still won=C2=B4t= do it, it > just doesn=C2=B4t sink in. Meanwhile I usually say: Wait 30 seconds a= fter last > write and then unplug and then hope for the best. > > I still think AmigaOS goes beyond all the other operation systems I k= now with > this feature. But well, I am not exactly sure how MS-DOS or Windows h= andle > this. I vaguely remember some retry prompt from MS-DOS, but it may ha= ve been > for another case. > > > But well, so yes, a warning in the log may just be completely useless= , cause > its too late then, for the data that was about to be safed. And if th= ere is no > data to be saved anymore, a warning does not make any sense either, c= ause > there isn=C2=B4t a problem. Yet, an aborted transaction means there w= as data to be > saved, so. > > So or so, this may be something to handle on the block or VFS layer a= nyway? > > Ciao, -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html