Your message dated Sun, 10 Feb 2019 17:41:47 +0000 with message-id <d15408cb4fd775d35260f624c6d8ed8292d045fd.camel@decadent.org.uk> and subject line Re: btrfs-tools: Atomic replacement of subvolumes is not possible has caused the Debian Bug report #587253, regarding btrfs: please support atomic replacement of subvolumes to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 587253: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587253 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: btrfs-tools: Atomic replacement of subvolumes is not possible
- From: Roger Leigh <rleigh@debian.org>
- Date: Sat, 26 Jun 2010 18:05:41 +0100
- Message-id: <20100626170541.18608.34161.reportbug@ravenclaw.codelibre.net>
Package: btrfs-tools Version: 0.19+20100601-3 Severity: normal rename(2) allows for the atomic replacement of files. Being able to atomically replace subvolume snapshots would be equally invaluable, since it would permit lock-free replacement of subvolumes. % btrfs subvolume snapshot <src> <dest> creates dest as a snapshot of src. However, if I want to do the converse, % btrfs subvolume snapshot <dest> <src> then <dest> is snapshotted as <src>/<dest>, i.e. not replacing the original subvolume, but going inside the original subvolume. Use case 1: I have a subvolume of data under active use, which I want to periodically update. I'd like to do this by atomically replacing its contents. I can replace the content right now by deleting the old subvolume and then snapshotting the new on in its place, but it's racy. It really needs to be replaced in a single operation, or else there's a small window where there is no data, and I'd need to resort to some external locking to protect myself. Use case 2: In schroot, we create btrfs subvolume snapshots to get copy-on- write chroots. This works just fine. We also provide direct access to the "source" subvolume, but since it could be snapshotted in an inconsistent state while being updated, we want to do the following: · snapshot source subvolume · update snapshot · replace source volume with updated snapshot I've filed this against btrfs-tools, but it may well need support in-kernel as well as support in the btrfs tool. Please could you forward this to the appropriate upstream(s)? Regards, Roger -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (550, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages btrfs-tools depends on: ii e2fslibs 1.41.12-2 ext2/ext3/ext4 file system librari ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-2 common error description library ii libuuid1 2.17.2-3.1 Universally Unique ID library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime btrfs-tools recommends no packages. btrfs-tools suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---
- To: 587253-done@bugs.debian.org
- Subject: Re: btrfs-tools: Atomic replacement of subvolumes is not possible
- From: Ben Hutchings <ben@decadent.org.uk>
- Date: Sun, 10 Feb 2019 17:41:47 +0000
- Message-id: <d15408cb4fd775d35260f624c6d8ed8292d045fd.camel@decadent.org.uk>
- In-reply-to: <20100626170541.18608.34161.reportbug@ravenclaw.codelibre.net>
- References: <20100626170541.18608.34161.reportbug@ravenclaw.codelibre.net>
Feature requests should be pursued upstream. Ben. -- Ben Hutchings The world is coming to an end. Please log off.Attachment: signature.asc
Description: This is a digitally signed message part
--- End Message ---