From owner-freebsd-fs@FreeBSD.ORG Fri Apr 12 15:59:47 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE859B46 for ; Fri, 12 Apr 2013 15:59:47 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id AB690FD7 for ; Fri, 12 Apr 2013 15:59:47 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id r13so2502192iar.5 for ; Fri, 12 Apr 2013 08:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=+tAF/14YlcVF1kxnDsVk6tFbGRdWqxL8l6nkNoDhqss=; b=Mk7zpjHGEAoOslt0atC1a4j5RFBo63S069cBMSBXFuImUkDnB0heZcrRxrMr2WZnn0 BQ9VWoAvVmtAvliAvt2kmVjJfnC8lMxB9S05deGASzZ/2dwFtSelBqPrGaG2TrOl7PqC Ru0rErdmHdMcEbjXf3bqDxm0pPOgvIjvXhhEY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=+tAF/14YlcVF1kxnDsVk6tFbGRdWqxL8l6nkNoDhqss=; b=hjGWgL1/cR3QjmGAB4slBVO+JL6p6c/+dhdBPv24MJZQ8Ehj0oG6RksHNy4Hs50fkp pJCyOwd+895Us/3EE14WdkskDPTWefehyjUqSOziu4btPr9L4ZhA8nE4K4wnWZl8GI2d RhYmhmo8MbZAjHJ+RyInA5tsIpzl2ROwpizNG7fIu8HktlXIRSarYrRnCMHUvHmhMGB3 LSbgIdRZoohbVW44lZ5MUFOM/l9OFqGHK63zYe0TMK8jQdlJoJA/F0l7cuFwlqn/aZx3 b0J4qOLU9k89Y4wkb8ulQM/6Zu0IvJqHG+3yiw403dPIKSvjsFHFwG7M6Zt6Vei16Dt7 lnXg== X-Received: by 10.50.154.72 with SMTP id vm8mr1563072igb.1.1365782387248; Fri, 12 Apr 2013 08:59:47 -0700 (PDT) Received: from vpn132.rw1.your.org (vpn132.rw1.your.org. [204.9.51.132]) by mx.google.com with ESMTPS id in10sm3494076igc.1.2013.04.12.08.59.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 08:59:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Does sync(8) really flush everything? Lost writes with journaled SU after sync+power cycle From: Kevin Day In-Reply-To: <20130411160253.V1041@besplex.bde.org> Date: Fri, 12 Apr 2013 10:59:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87CC14D8-7DC6-481A-8F85-46629F6D2249@dragondata.com> <20130411160253.V1041@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnx2wu0umS5Kd+hZHA2TU4rVAEZslfdRYTx5RDtUFql0CKyfIWxqN3KiNqrO+bhn2c0AF0o 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: Fri, 12 Apr 2013 15:59:47 -0000 On Apr 11, 2013, at 1:30 AM, Bruce Evans wrote: >=20 > sync(2) only schedules all writing of all modified buffers to disk. = Its > man page even says this. It doesn't wait for any of the writes to = complete. > Its man page says that this is a BUG, but it is intentional and sync() = has > always done this. There is no way for sync() to guarantee that all = modified > buffers have been written to disk when it returns, since even if it = waited, > buffers might be modified while it is returning. Perhaps even ones = that > would take 8 seconds to complete can be written in the few nanoseconds = that > it takes to return. >=20 > sync(8) is just a wrapper around sync(2). One that doesn't even check > for errors. Not that it could handle sync() failure. Its man page > bogusly first claims that it "forces completion". This is not > completely wrong, since it doesn't claim that the completion occurs > before sync(8) exits. But then it claims that sync(8) is suitable "to > ensure that all disk writes have been completed in a way not suitably > done by reboot(8) or halt(8). This wording is poor, unless it is > intentionally weaselishly worded so that it doesn't actually claim > full completion. 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). > It only claims more suitable completion than with > reboot or halt. Actually, completion is not guaranteed, and what > sync(8) provides is just less unsuitable than what reboot and halt > provide. >=20 > To ensure completion, you have to freeze the file systems of interest > before rebooting. I don't know of any ways to do this from userland > except mount -u -o ro or unmount. >=20 > There should be a syscall to cause syncing with waiting. The kernel > has a wait option for syncing, but doesn't use it for sync(2). But > using this would only reduce the races. >=20 > Bruce 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. If sync(8) isn't starting the write flush immediately, but does return = immediately, I'm having trouble figuring out a situation where calling = sync would ever accomplish anything useful, other than possibly creating = a window where the filesystem could be damaged if a crash happens. -- Kevin