From patchwork Fri Feb 3 15:44:53 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Graham Cobb X-Patchwork-Id: 9554445 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 89E3560424 for ; Fri, 3 Feb 2017 15:45:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6E86828428 for ; Fri, 3 Feb 2017 15:45:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 61CEA2847A; Fri, 3 Feb 2017 15:45:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_TVD_MIME_EPI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6DA0828428 for ; Fri, 3 Feb 2017 15:45:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751088AbdBCPpC (ORCPT ); Fri, 3 Feb 2017 10:45:02 -0500 Received: from zaphod.cobb.me.uk ([213.138.97.131]:38700 "EHLO zaphod.cobb.me.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750956AbdBCPo7 (ORCPT ); Fri, 3 Feb 2017 10:44:59 -0500 Received: by zaphod.cobb.me.uk (Postfix, from userid 107) id 1D79D9B940; Fri, 3 Feb 2017 15:44:55 +0000 (GMT) Received: from black.home.cobb.me.uk (unknown [192.168.0.205]) by zaphod.cobb.me.uk (Postfix) with ESMTP id 90E269B8D3; Fri, 3 Feb 2017 15:44:53 +0000 (GMT) Received: from [192.168.0.211] (novatech.home.cobb.me.uk [192.168.0.211]) by black.home.cobb.me.uk (Postfix) with ESMTPS id 5BFE95FBB3; Fri, 3 Feb 2017 15:44:53 +0000 (GMT) Subject: Re: btrfs receive leaves new subvolume modifiable during operation To: "Austin S. Hemmelgarn" , linux-btrfs@vger.kernel.org References: <1485905578.6441.20.camel@gmail.com> <4edfd08e-8d7f-d8d7-bdea-0589b46e4d2b@gmail.com> <7ead5d42-9c00-b2df-3fbf-5b8f287760f6@cobb.uk.net> <5c503d69-aaed-680f-de30-75a7323bc753@cobb.uk.net> <1b69d1a8-c08b-c9f3-c95b-1d7d71c7d642@cobb.uk.net> <092c2028-f132-83b1-5f10-d84d374a8bb3@gmail.com> From: Graham Cobb Message-ID: Date: Fri, 3 Feb 2017 15:44:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <092c2028-f132-83b1-5f10-d84d374a8bb3@gmail.com> Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 03/02/17 12:44, Austin S. Hemmelgarn wrote: > I can look at making a patch for this, but it may be next week before I > have time (I'm not great at multi-tasking when it comes to software > development, and I'm in the middle of helping to fix a bug in Ansible > right now). That would be great, Austin! It is about 15 years since I last submitted a patch under kernel development patch rules and things have changed a fair bit in that time. So if you are set up to do it that sounds good. As a starting point, I have created a suggested text (patch attached). diff --git a/Documentation/btrfs-receive.asciidoc b/Documentation/btrfs-receive.asciidoc index 6be4aa6..db525d9 100644 --- a/Documentation/btrfs-receive.asciidoc +++ b/Documentation/btrfs-receive.asciidoc @@ -31,7 +31,7 @@ the stream, and print the stream metadata, one operation per line. 3. default subvolume has changed or you didn't mount the filesystem at the toplevel subvolume -A subvolume is made read-only after the receiving process finishes succesfully. +A subvolume is made read-only after the receiving process finishes succesfully (see BUGS below). `Options` @@ -73,6 +73,16 @@ EXIT STATUS *btrfs receive* returns a zero exit status if it succeeds. Non zero is returned in case of failure. +BUGS +---- +*btrfs receive* sets the subvolume read-only after it completes successfully. +However, while the receive is in progress, users who have write access to files +or directories in the receiving 'path' can add, remove or modify files, in which +case the resulting read-only subvolume will not be a copy of the sending subvolume. + +If the intention is to create an exact copy, the receiving 'path' should be protected +from access by users until the receive has completed and the subvolume set to read-only. + AVAILABILITY ------------ *btrfs* is part of btrfs-progs.