From owner-freebsd-fs@FreeBSD.ORG Sat Apr 13 10:27:47 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC4F37F9 for ; Sat, 13 Apr 2013 10:27:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5A64FBE0 for ; Sat, 13 Apr 2013 10:27:46 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3DARYAX006865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Apr 2013 20:27:35 +1000 Date: Sat, 13 Apr 2013 20:27:34 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kevin Day Subject: Re: Does sync(8) really flush everything? Lost writes with journaled SU after sync+power cycle In-Reply-To: Message-ID: <20130413200708.J1165@besplex.bde.org> References: <87CC14D8-7DC6-481A-8F85-46629F6D2249@dragondata.com> <20130411160253.V1041@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Ov0XUFDt c=1 sm=1 a=Cguo-lYZyhEA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=5GGpcXspQ0YA:10 a=gIcydfCnhbxikQVEtaIA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: "freebsd-fs@FreeBSD.org Filesystems" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 10:27:47 -0000 On Fri, 12 Apr 2013, Kevin Day wrote: > On Apr 11, 2013, at 1:30 AM, Bruce Evans wrote: >> >> sync(2) only schedules all writing of all modified buffers to disk. Its >> ... >> >> sync(8) is just a wrapper around sync(2). One that doesn't even check >> ... > > And on the flip side, the man page for syncer says: > > It is possible on some systems that a sync(2) occurring simultaneously with a crash may cause file system damage. See fsck(8). That is not useful. It was copied from update(8) to update(4misplaced) and then to syncer(4misplaced). It should go without saying that a crash may cause file system damage irrrespective of whether it occurs simultaneously with sync(2). Apart from that: back in 1996 when these words in update(4) were written, all syncs were done by update(8) calling sync(2). With the syncer daemon, crashes may also occur concurrently with syncer daemon activity, and that and not sync(2) became ths most common source of crashes with syncs. I thing these words are just a hint about the bug that panic() calls sync(). Back in 1996, there was little locking for sync against itself (perhaps it could deadlock). Now there is lots of locking for normal sync activity (e.g., sync(2) vs the syncer daemon). I don't know how this acts in panic() but guess that it doesn't really work. So crashes may cause file system damage, but this has little to do with sync(2) or even the syncer daemon (the sync() in panic() either has to blow away all locks so that it can complete, or possibly deadlock. If it blows away all locks then it may cause damage directly, and if it deadlocks then you cause the damage use reset or power cycling). Of course, nothing about this can be seen in fsck(8). Now there are many foofs_fsck(8)'s where the things to be seen would have been moved to if there were any. > ... > I understand that sync(8) returns immediately, I guess my confusion is that calling sync(8) doesn't seem to cause *any* writes to happen. > > I can have the system completely idle (absolutely no processes running that could cause any filesystem activity), call sync(8), and watching gstat(8) can see no write activity happen at all, even waiting 10+ seconds afterwards, where as "mount -u -o ro -f /" causes an instant flurry of writes to happen. My understanding was that even though sync returned immediately, flushing would also start immediately, and leave the system in a safe point, at least until another write happens. I thought that you got the flurry of writes from sync() too, but they took 10+ seconds. Perhaps an fs bug. Bruce