Date: Thu, 17 May 2018 18:46:45 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Stefan Esser <se@freebsd.org> Cc: FreeBSD File-Systems <freebsd-fs@freebsd.org> Subject: Re: [Bug 210316] panic after trying to r/w mount msdosfs on write protected media Message-ID: <20180517183323.I1485@besplex.bde.org> In-Reply-To: <8c1cb4b3-633a-5b14-0713-727b03f44f4e@freebsd.org> References: <bug-210316-3630@https.bugs.freebsd.org/bugzilla/> <bug-210316-3630-eXVbCR5qFd@https.bugs.freebsd.org/bugzilla/> <20180517163709.F1129@besplex.bde.org> <8c1cb4b3-633a-5b14-0713-727b03f44f4e@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 May 2018, Stefan Esser wrote: > Am 17.05.18 um 09:14 schrieb Bruce Evans: >> >> [.. about markvoldirty() in msdosfs not being too good] >> >> One idea for improving this is to delay markvoldirty() until the first >> explicit write().=A0 Also, don't clobber the disk to write atimes even i= f >> the fs is mounted rw and without -noatime (it takes something like FAT32 >> before atimes even exist in msdosfs).=A0 msdosfs has always had an inter= nal >> flag pm_fmod which was apparently intended for a similar optimization, b= ut >> it is useless since it is always set on successful rw mounts and not cle= ared >> 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.=A0 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 tha= t >> the fs is usually clean if it is not written to often.=A0 All versions o= f >> 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 coul= d > 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)= =2E > > In short, the suggestion is to down-grade the mount state of any file-sys= tem > not used for some configurable time to R/O, with an automatic upgrade to = R/W > on the next write attempt. > ... I want this more for ffs too. Anither idea is to have a per-cylinder-group (cg) dirty flag and only fsck the dirty cg's. Then an enormous number of cg's would be a feature. Most would remain clean unless locality is bad. This is too large a project for me. I only have small data and just use small ffs file systems and mount m= ost of them ro most of the time. Bruce From owner-freebsd-fs@freebsd.org Thu May 17 09:03:27 2018 Return-Path: <owner-freebsd-fs@freebsd.org> 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 3B3D1EE1240 for <freebsd-fs@mailman.ysv.freebsd.org>; Thu, 17 May 2018 09:03:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CCCB67494C for <freebsd-fs@freebsd.org>; Thu, 17 May 2018 09:03:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8D736EE123F; Thu, 17 May 2018 09:03:26 +0000 (UTC) Delivered-To: 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 796ECEE123E for <fs@mailman.ysv.freebsd.org>; Thu, 17 May 2018 09:03:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 100117494B for <fs@FreeBSD.org>; Thu, 17 May 2018 09:03:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 4203AF98E for <fs@FreeBSD.org>; Thu, 17 May 2018 09:03:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w4H93PCr098435 for <fs@FreeBSD.org>; Thu, 17 May 2018 09:03:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w4H93Pjv098433 for fs@FreeBSD.org; Thu, 17 May 2018 09:03:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 191858] [msdosfs] [panic] Disposed page 0xfffff807d41eeb60 is dirty Date: Thu, 17 May 2018 09:03:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vladislav.movchan@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: <bug-191858-3630-p2JxGUJ69A@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-191858-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-191858-3630@https.bugs.freebsd.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Filesystems <freebsd-fs.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-fs>, <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>; List-Post: <mailto:freebsd-fs@freebsd.org> List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-fs>, <mailto:freebsd-fs-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 17 May 2018 09:03:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191858 Vladislav Movchan <vladislav.movchan@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vladislav.movchan@gmail.com --- Comment #2 from Vladislav Movchan <vladislav.movchan@gmail.com> --- I suppose this problem (panic: Freeing unused sector) might be caused by the same reason described in bug 213507. I.e. in directories with the large amount of files (directories which occupy more than one cluster) garbage-like directory entries could appear. Attempt to interpret such dentries (which are basically random data) could = lead to unexpected results. Could you please try to reproduce this on CURRENT after base r333693? To reproduce this problem myself I tried to create several hundreds of directories with 500 to 1000 small files in each and removing them all at o= nce. I repeated this procedure multiple times but was not able to trigger this on r333698. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180517183323.I1485>