From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45F58C169C4 for ; Thu, 31 Jan 2019 20:25:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 169FB218AF for ; Thu, 31 Jan 2019 20:25:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=colorremedies-com.20150623.gappssmtp.com header.i=@colorremedies-com.20150623.gappssmtp.com header.b="dd/36tKU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727580AbfAaUZW (ORCPT ); Thu, 31 Jan 2019 15:25:22 -0500 Received: from mail-lj1-f182.google.com ([209.85.208.182]:42623 "EHLO mail-lj1-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726848AbfAaUZW (ORCPT ); Thu, 31 Jan 2019 15:25:22 -0500 Received: by mail-lj1-f182.google.com with SMTP id l15-v6so3805973lja.9 for ; Thu, 31 Jan 2019 12:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorremedies-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8JJ5f2ApufwEWzoviIHDTTHaod+3pccu1a8Q4Y7cGeA=; b=dd/36tKUi0YD3SERy+VgS+kqUDUedJTL+tjREOyTBANwLG7nxm8ePUT5Nj3CRDfoKb 6ljy0AJWy9z01KzqKR/58MUpcwzcP15RJBvgwUw+nkdj4vXOFSaiovnAFaY7J/+PPuKD OKmZuVN0z7fknQZ8RHhLBLRWOY2+dkl0vT3EFn0zO1RUT5469jUqgzalMg+WzKgN4FUx SDViHsy8tg3MXcdLOvPqvZTALywR442nWo6ee9skCD28uAbrSBcFZMMFLn0LAqbvls1i 40gCmX/GP4Xm7Hvlx3JGuHZ6i4gBabcPyatFsCJb9GruvAoerXh7E7NiJ60Y5fteBXbL Ot/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8JJ5f2ApufwEWzoviIHDTTHaod+3pccu1a8Q4Y7cGeA=; b=UxywV97aKBq5Fqsn+UknF2X+6s2BXvRPdy0Z9dRexNQSgGD7EFrlgnltb6LoSAkuO7 CesYKAxbz9cTRnreIgXgikMpJtjrithfxlfVXaL9P0k6OOISVWGi+TfJ+rmLXaJZOciD dr3ZPg32MC3GCUvMUPbcqhlXaqjdY/SJBnqeXOAlZgwRKsJfDd8zhplVuidJdanuUFYv SxVSmnhyKHgZJsmsx6wPIS3ZYO2zL9Bs+awVZgxtvRVOC7jclEUp9AQdBeMQKxyji71T TlehushoBIySG8i5XSbqEUnxvUv6rgJzjNvMjSMaiLqYAYqyFOmb/ihHVKqjx1cTWgN5 rxKw== X-Gm-Message-State: AJcUukdjvBLEzferGkcG8KTlWZnM5epKKjG14zjbEAvEXDHfFVR1tiFH n6uxhRFLyJQIe23L1SS9OWpHuz6EaT/cIyg/3y8xtQ== X-Google-Smtp-Source: ALg8bN5mKNuqqXp0wQNL1p1i0I5w7LRQ9YDt0e683lXuLQNxyzdlOr/Jehwu7WJRA14ybBycu0TQTkgYQ9xiGPlPFWM= X-Received: by 2002:a2e:58b:: with SMTP id 133-v6mr27356885ljf.127.1548966320358; Thu, 31 Jan 2019 12:25:20 -0800 (PST) MIME-Version: 1.0 References: <20190128125044.GC27972@quack2.suse.cz> <20190128212642.GQ4205@dastard> <20190129001826.GV4205@dastard> <20190129230129.GD4205@dastard> In-Reply-To: From: Chris Murphy Date: Thu, 31 Jan 2019 13:25:08 -0700 Message-ID: Subject: Re: [LSF/MM TOPIC] Lazy file reflink To: Amir Goldstein Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel , linux-xfs Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Jan 30, 2019 at 6:30 AM Amir Goldstein wrote: > generic_remap_file_range_prep() does not require that source > file is not immutable. Does XFS? I don't know if "immutable" > has ever been defined w.r.t file layout on disk. has it? > I recon btrfs re-balancing would not stop at migrating "immutable" > file blocks would it? chattr +i does not pin the file to a particular physical location on a device or even on a particular device, at least on Btrfs. A balance operation, including device replace, or device add+remove, or changing the raid profile, isn't inhibited - such operations happen at the block group level, somewhat similar to LVM pvmove. A directory containing an immutable file cannot be deleted until immutable flag is unset; but a subvolume containing an immutable file is deleted without complaint when using 'btrfs sub del'. I'm pretty sure that's expected. Further, looks like now 'rmdir' and 'rm -rf' will remove a subvolume; but in the case of it containing an immutable file, 'rm -rf' fails just as if it were a directory even though 'btrfs sub del' succeeds. -- Chris Murphy