From owner-freebsd-fs@freebsd.org Thu May 17 13:24:27 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 A8029EF0F69 for ; Thu, 17 May 2018 13:24:27 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) (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 2CEED7F431 for ; Thu, 17 May 2018 13:24:27 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd13.aul.t-online.de (fwd13.aul.t-online.de [172.20.27.62]) by mailout02.t-online.de (Postfix) with SMTP id 08F9441800EA; Thu, 17 May 2018 15:24:25 +0200 (CEST) Received: from Stefans-MacBook-Pro-10.local (TlW4t4ZHwh9jgBvSXZ+7AgAbD4Fwy388CZxn0EQGsrl00d5X7YNIu8u-VQMf2pagOO@[84.154.105.176]) by fwd13.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1fJItG-0KvuqG0; Thu, 17 May 2018 15:24:18 +0200 Subject: Re: [Bug 210316] panic after trying to r/w mount msdosfs on write protected media To: Konstantin Belousov Cc: Bruce Evans , FreeBSD File-Systems References: <20180517163709.F1129@besplex.bde.org> <8c1cb4b3-633a-5b14-0713-727b03f44f4e@freebsd.org> <20180517114235.GI6887@kib.kiev.ua> 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: <57342a02-ddf3-0a41-d394-74b8f8a27a83@freebsd.org> Date: Thu, 17 May 2018 15:24:15 +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: <20180517114235.GI6887@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: TlW4t4ZHwh9jgBvSXZ+7AgAbD4Fwy388CZxn0EQGsrl00d5X7YNIu8u-VQMf2pagOO X-TOI-MSGID: 8fe9d50e-b0a9-427d-8dae-c71e614d964b 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 13:24:27 -0000 Am 17.05.18 um 13:42 schrieb Konstantin Belousov: > On Thu, May 17, 2018 at 10:04:01AM +0200, Stefan Esser wrote: >> 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. > Downgrade to ro revokes all file descriptors opened for write, otherwise > it is not a downgrade. Really? I was not aware of that effect, but I think it can be dealt with in a similar way as an unmount request for a file system with open files. In the case of SD cards or other media used for file transfer, it is unlikely that a file system is in active use for an extended time (except for the duration of the file transfer). This is obviously not true for embedded ARM platforms that use SD cards for normal file systems. But the revocation of file file descriptors open for writing does not appear necessary to me. A clean state should be reached (same as a vetoed unmount request typically creates) and then a "clean" superblock could be written, which only corresponds to the state of the file system, not that individual files had their stdio buffers flushed and the file completely written. The flushing of stdio buffers would cause a remount of the partition as R/W. And this will obviously only ever occur, if the file descriptors have not been revoked. > This would be a huge mess. Yes, definitely. But it has been more than a decade since I looked into this topic and AFAIR, it was sufficient to just wait for no dirty buffers, then set the partition to R/O (and at the same time write a clean super-block) and have a flag that allows restarting writes after marking the super-block dirty again. It is not necessary to actually perform a R/O remount. The only guarantee required is, that the super-block is not marked clean if there are any outstanding writes (to make sure, that data blocks and meta-data are consistent) when a clean super-block is written, and that the next write attempt is intercepted and causes the super-block to be dirtied before the write is allowed to change any on disk data. Regards, STefan