From owner-freebsd-bugs@FreeBSD.ORG Sat Oct 13 06:40:01 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A1BAF84 for ; Sat, 13 Oct 2012 06:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 3F19E8FC0C for ; Sat, 13 Oct 2012 06:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9D6e1Iw009157 for ; Sat, 13 Oct 2012 06:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9D6e1BI009156; Sat, 13 Oct 2012 06:40:01 GMT (envelope-from gnats) Resent-Date: Sat, 13 Oct 2012 06:40:01 GMT Resent-Message-Id: <201210130640.q9D6e1BI009156@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Martin Birgmeier Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88E3FDF1 for ; Sat, 13 Oct 2012 06:30:25 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 58A2A8FC0C for ; Sat, 13 Oct 2012 06:30:25 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id q9D6UOI4069004 for ; Sat, 13 Oct 2012 06:30:24 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id q9D6UON8069003; Sat, 13 Oct 2012 06:30:24 GMT (envelope-from nobody) Message-Id: <201210130630.q9D6UON8069003@red.freebsd.org> Date: Sat, 13 Oct 2012 06:30:24 GMT From: Martin Birgmeier To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/172656: [zfs] zfs rollback leaves stale data in the buffer cache X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 06:40:01 -0000 >Number: 172656 >Category: kern >Synopsis: [zfs] zfs rollback leaves stale data in the buffer cache >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Oct 13 06:40:00 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Martin Birgmeier >Release: FreeBSD 8.2.0 release >Organization: MBi at home >Environment: FreeBSD hal.xyzzy 8.2-RELEASE FreeBSD 8.2-RELEASE #4: Sat Aug 27 09:30:11 CEST 2011 root@hal.xyzzy:/z/OBJ/FreeBSD/amd64/RELENG_8_2_0_RELEASE/src/sys/XYZZY_SMP amd64 >Description: I am using a program whose purpose is to efficiently copy disk partitions to image files stored on zfs. Multiple backups in time are kept using snapshots of the file system on which these image files reside. The program uses mmap(2) to map an image file into memory, then reads the disk partition to be backup up in fixed-size blocks (default 128k). For each block, it first compares the already stored data with the new one using memcmp(3), and does a write using memcpy(3) only if there is a mismatch. In this way, only the blocks which have changed are really written, keeping the zfs snapshots small. Today I aborted such a backup after about 20000 blocks, of which about 20% were rewritten, and decided to do a zfs rollback of the backup file system and restart the backup again. To my surprise, the program indicated that these first 20000 blocks were already all identical, i.e., 0% had to be rewritten. Only after those 20000 blocks further rewrites started to occur. I let this run for a while and then aborted again, this time without a zfs rollback. Restarting now resulted in about 20% of the first 20000 blocks being rewritten. This indicates to me that the buffer cache was not cleared when the rollback was executed, and was only purged by data arriving later. However, the expected behavior clearly is that along with the rollback, the buffer cache is also cleared. On Oracle's web site, the rollback operation is described as being equivalent to an unmount, rollback, and remount operation of the file system in question. The unmount should clear the cache. >How-To-Repeat: See description above describing the use case. >Fix: >Release-Note: >Audit-Trail: >Unformatted: