From owner-freebsd-fs@freebsd.org Thu May 17 08:12:12 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC7EBEDDF29 for ; Thu, 17 May 2018 08:12:11 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77D9A72926 for ; Thu, 17 May 2018 08:12:11 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd17.aul.t-online.de (fwd17.aul.t-online.de [172.20.27.64]) by mailout04.t-online.de (Postfix) with SMTP id 67485419F8C2; Thu, 17 May 2018 10:04:09 +0200 (CEST) Received: from Stefans-MacBook-Pro-10.local (bRAWReZCYhdRPeo0RTSvpqMZpD2xoL1oUrjbN12MmV7KehE3ZSPC5FIor8JKUvjZPS@[84.154.105.176]) by fwd17.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1fJDtK-2Wh7tg0; Thu, 17 May 2018 10:04:02 +0200 Subject: Re: [Bug 210316] panic after trying to r/w mount msdosfs on write protected media To: Bruce Evans , FreeBSD File-Systems References: <20180517163709.F1129@besplex.bde.org> From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNKVN0ZWZhbiBFw59lciAoWWFob28hKSA8c3QuZXNzZXJAeWFob28uZGU+wsCWBBMBCgBA AhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AWIQSjceplnAvsyCtxUxNH67XvWv31RAUC WvLvqwUJCyUBEwAKCRBH67XvWv31REySCACc6vqcSFQCRyBRc2CV5ZBjbbnTy7VBoXbUS3/c 4Hn8I0YQ39q7//2z8vYsgLeM1mMXL4PUIU/0f0dBAFBLpxV7bntGzyCJls6SeGS/qcQKhqaI 6I7NcWg8OkIJIhUL6q238cS1ql9pU65fyHe0PP8JS08m81PDpX2/4wTE6h2jgYUy55eXRzoF MEjr1S8SSnidsBem27o7iWu9ltJsUtE86071iZlLzbuHv2nvucrjAV9cK9tHrxYT/YiY8QhT L48iWj2xIjLjg1ebmgIFZ2k881we/KTIoUugqOOR1gDSc4qwM8CA388cN3frjtl98CwhAT5T UV8tIDqri+/Z1AKwzsBNBFVxiRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1M kVnCAhFbY9oecTB/togdKtfiloavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNU eMm+gtTDMSvloGAfr76RtFHskdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPq z3B4IjiDAWTO2obD1wtAvSuHuUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSA ly+hkY7NrDZydMMXVNQ7AJQufWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpq ThDMurqtQFn1ABEBAAHCwHwEGAEKACYCGwwWIQSjceplnAvsyCtxUxNH67XvWv31RAUCWvLv qwUJCyUBGQAKCRBH67XvWv31RLnrB/9gzcRlpx71sDMosoZULWn7wysBJ/8AIEfIByRaHQe3 pn/KwE57pB+zFbbQqB7YzeZb7/UUgR4zU2ZbOcEfwDZcHUbj0B3fGRsS3t0uiLlAd8w0sBZb SxrqzjdpDjIbOZkxssqUmvrsN67UG1AFWH9aD24keBS7YjPBS8hLxPeYV+Xz6vUL8fRZje/Z JgiBMIwyj6g2lH/zkdnxBdC0iG1xxJOLTaghMMeQyCdH6ef8+VMyAlAJsMckbOTvx63tY8z7 DFcrnTJfbe1EziRilVsEaK8tTzJzhcTfos+f3eBYWEilxe5HzIhYKJeC7lmsSUcGwa6+9VRg a0ctmi9Z8OgX Message-ID: <8c1cb4b3-633a-5b14-0713-727b03f44f4e@freebsd.org> Date: Thu, 17 May 2018 10:04:01 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180517163709.F1129@besplex.bde.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ID: bRAWReZCYhdRPeo0RTSvpqMZpD2xoL1oUrjbN12MmV7KehE3ZSPC5FIor8JKUvjZPS X-TOI-MSGID: cf91b1af-dd1f-4ef4-a04e-440fa0da067a X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 08:12:12 -0000 Am 17.05.18 um 09:14 schrieb Bruce Evans: > On Thu, 17 May 2018 a bug that doesn't want replies@freebsd.org wrote: > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210316 >> >> --- Comment #14 from Andriy Gapon --- >> (In reply to Conrad Meyer from comment #13) >> >> Indeed, if we talk about the general behaviour. >> >> I see that I utterly failed to explain that I was thinking purely in a context >> of what msdos does in markvoldirty. >> Right now that code can leave behind a perpetually dirty buffer and I was >> thinking how that can be avoided. >> >> Maybe markvoldirty should do >>    bp = getblk(...) >>    bp->b_flags |= B_INVAL | B_RELBUF | B_NOCACHE; >>    bp->b_flags &= ~(B_ASYNC | B_CACHE); >>    brelse(bp); >> after a failed write? >> Looks clumsy, but should work. > > I think this is the only way to clean up the buffer cache. > >> Or maybe markvoldirty should not use buffer cache for its write? >> It could use g_write_data, for example.  But that sounds like layering >> violation. > > Not a good way. > > Markvoldirty() was obtained from apple and fixed a bit by me, but is still > very bad, without even this write protection bug. > > Before it was implemented, you could use removable media with write > protection on, and have no writes occur even if you forgot to mount > with ro, and nothing bad happened if the media was removed without > unmounting provided it was never explicitly written to.  Now, > markvoldirty() ensures that bad things happen if the media is removed > without unmounting, even if the media is writeable initially so that > markvoldirty() doesn't fail. > > I thought that failures were handled better.  markvoldirty() returns > bwrite().  There is a lot of error handling for this, but this ends > up as just markvoldirty() back to clean with the result voided for the > final call.  For unwriteable media, the buffer remains in the buffer > cache forever. > > One idea for improving this is to delay markvoldirty() until the first > explicit write().  Also, don't clobber the disk to write atimes even if > the fs is mounted rw and without -noatime (it takes something like FAT32 > before atimes even exist in msdosfs).  msdosfs has always had an internal > flag pm_fmod which was apparently intended for a similar optimization, but > it is useless since it is always set on successful rw mounts and not cleared > until unmount, and it is write-only except for a check in msdosfs_sync() > where it just causes a panic if it is not set.  The voldirty flag and > any internal dirty flags should also be set to clean if the file system > is not written to for some time after a successful complete sync, so that > the fs is usually clean if it is not written to often.  All versions of > Windows that I have tried seem to do this. Some 20 years ago I had to work with AIX machines, and I found that they offered a nice feature for accesses to removable media (floppy disks, at that time). If such a media was not written to for a few seconds, it could be removed without unmounting. I proposed to implement a timer that was triggered when the number of dirty buffers for a partition drops to zero and that is canceled when the partition is written to (this does not need to be a timer of course, polling for that case every few seconds works as well), at that time. And pre-soft-updates and journaling that feature had also been of advantage for UFS file systems that are rarely written but where the cause of most fsck delay after an unclean shutdown. In case that a media (whether removable or not) was mounted R/W and not written to (had no dirty buffers) for more than a few seconds, the mount could be downgraded to R/O (in the same way as by a "mount -u -o ro"). A flag that recorded the fact, that this partition may be written to could then be checked in the "write to R/O partition" error case, and if the file system was only temporarily set to R/O, it could be treated like a first access to a writable partition (i.e., write a dirty flag into the super-block or whatever action the file system performs when mounted R/W). In short, the suggestion is to down-grade the mount state of any file-system not used for some configurable time to R/O, with an automatic upgrade to R/W on the next write attempt. I did not try to fully implement that feature when floppy disks became less and less relevant, but with USB and SD media being used as writable media, today, the same situation exists as with floppy disks some 20 years ago. The only requirement for such a mechanism is that the number of dirty buffers per partition is known and accessible for a polling every few seconds, that causes the temporary down-grade to R/O to be triggered. Everything else is trivial (i.e., just check a flag in the "write to R/O" error path and clear the R/O flag in such a way that the dirty flag gets written). That requires a (trivial) change in each file system that wants to be able to upgrade to R/W after the temporary downgrade to R/O, though. Regards, STefan