Date: Sat, 13 Oct 2012 06:30:24 GMT From: Martin Birgmeier <Martin.Birgmeier@aon.at> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/172656: [zfs] zfs rollback leaves stale data in the buffer cache Message-ID: <201210130630.q9D6UON8069003@red.freebsd.org> Resent-Message-ID: <201210130640.q9D6e1BI009156@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210130630.q9D6UON8069003>