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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B1F8C4332F for ; Thu, 15 Dec 2022 20:57:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229488AbiLOU5o (ORCPT ); Thu, 15 Dec 2022 15:57:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229480AbiLOU5n (ORCPT ); Thu, 15 Dec 2022 15:57:43 -0500 Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0041A528AD for ; Thu, 15 Dec 2022 12:57:41 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id f9so439458pgf.7 for ; Thu, 15 Dec 2022 12:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=FGlgG65UXPdq7YvcqlgjjW36/ERNfTZqDYuDWENGbu8=; b=v4T1uygL5ZIuGoU1nKeJ2S6HM0bKfVT8vOSMQRBFHs7ZdQOKZm2ZLafTTVXRMN8n2r 0ZUf2QIvTfXYMpoD2jwtabM9kr9JGGrRrkIEN9NqLlvXlGArXNJiumj3A1k4tESITmdl WFb466dCE568BXZh+aYXBerMt29s5RS9bqmeHNLzLmzmwKtqE5trAqqK7JgBKwkVdHu6 w9zX9He9+eY5aI2OVhjUUaIJOFMe1/7ZfQbxAAH/ZdRT9onbGCy5fH54dPZBeS+kdNKx 2KSBE5vriWptao3hYIm+d/+RsGLbIWHanDkJJqFByjs/TgNHNI767QKuZmM+mF6a5p+6 26ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FGlgG65UXPdq7YvcqlgjjW36/ERNfTZqDYuDWENGbu8=; b=XKkbsgYptfi4qXjEmx7gYODU/R/KQKBGuhLOVYElz443B98TAv1QjQQRl4cpb7Mr3D PYap3UoRW5NP0ATRrAsmb1ilXSJH9d22qQ842TTfNRByqRC0d8fwKkXyylwUfPLJpRpN hXkMJ8LEU40/a4Uipk2PMyB9ZQVqZFkyyLtK4i4NTDPh/zOCUcMPV35DDUbKBxgLJZtY C+7Kvsz/epWHA/miYPai9Ld+EBrCWnIIPfoVGTcdvrqbtn3jAlCmGRhxMP4KcP64r0L7 4NJBnK3XghuWpTcc/4FRQzOurABD5vJtT9gIElN0ohkwiwpdh76qjW5UJRs+xq7FmiVS rUHQ== X-Gm-Message-State: ANoB5pngHFTS892uz634uB/LQ6+rD9H3JJutObJ9qMDIf6QXlq+/M8bd j4DWPo/AgQF2Oq79L4vglqDf8c1rBat5ZqA7 X-Google-Smtp-Source: AA0mqf7+C0W4VsYl4Q0pz20esq6X7Hc9K9Y5ZTA8oeFHjubSafBeKjFUoLBintjBMQS1JAPSm9kBJg== X-Received: by 2002:a62:53c5:0:b0:563:cc80:fb66 with SMTP id h188-20020a6253c5000000b00563cc80fb66mr27930943pfb.0.1671137861454; Thu, 15 Dec 2022 12:57:41 -0800 (PST) Received: from dread.disaster.area (pa49-181-138-158.pa.nsw.optusnet.com.au. [49.181.138.158]) by smtp.gmail.com with ESMTPSA id k18-20020aa79992000000b0056d7cc80ea4sm36829pfh.110.2022.12.15.12.57.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 12:57:40 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1p5vIP-008sJh-34; Fri, 16 Dec 2022 07:57:37 +1100 Date: Fri, 16 Dec 2022 07:57:37 +1100 From: Dave Chinner To: Eric Biggers Cc: Andrey Albershteyn , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH 00/11] fs-verity support for XFS Message-ID: <20221215205737.GD1971568@dread.disaster.area> References: <20221213172935.680971-1-aalbersh@redhat.com> <20221213221139.GZ3600936@dread.disaster.area> <20221214230632.GA1971568@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Wed, Dec 14, 2022 at 10:47:37PM -0800, Eric Biggers wrote: > On Thu, Dec 15, 2022 at 10:06:32AM +1100, Dave Chinner wrote: > > > Well, my proposal at > > > https://lore.kernel.org/r/20221028224539.171818-2-ebiggers@kernel.org is to keep > > > tracking the "verified" status at the individual Merkle tree block level, by > > > adding a bitmap fsverity_info::hash_block_verified. That is part of the > > > fs/verity/ infrastructure, and all filesystems would be able to use it. > > > > Yeah, i had a look at that rewrite of the verification code last > > night - I get the gist of what it is doing, but a single patch of > > that complexity is largely impossible to sanely review... > > Thanks for taking a look at it. It doesn't really lend itself to being split > up, unfortunately, but I'll see what I can do. > > > Correct me if I'm wrong, but won't using a bitmap with 1 bit per > > verified block cause problems with contiguous memory allocation > > pretty quickly? i.e. a 64kB bitmap only tracks 512k blocks, which is > > only 2GB of merkle tree data. Hence at file sizes of 100+GB, the > > bitmap would have to be kvmalloc()d to guarantee allocation will > > succeed. > > > > I'm not really worried about the bitmap memory usage, just that it > > handles large contiguous allocations sanely. I suspect we may > > eventually need a sparse bitmap (e.g. the old btrfs bit-radix > > implementation) to track verification in really large files > > efficiently. > > Well, that's why my patch uses kvmalloc() to allocate the bitmap. > > I did originally think it was going to have to be a sparse bitmap that ties into > the shrinker so that pages of it can be evicted. But if you do the math, the > required bitmap size is only 1 / 2^22 the size of the file, assuming the Merkle > tree uses SHA-256 and 4K blocks. So a 100MB file only needs a 24-byte bitmap, > and the bitmap for any file under 17GB fits in a 4K page. > > My patch puts an arbitrary limit at a 1 MiB bitmap, which would be a 4.4TB file. > > It's not ideal to say "4 TB Ought To Be Enough For Anybody". But it does feel > that it's not currently worth the extra complexity and runtime overhead of > implementing a full-blown sparse bitmap with cache eviction support, when no one > currently has a use case for fsverity on files anywhere near that large. I think we can live with that for the moment, but I suspect that 4TB filesize limit will become an issue sooner rather than later. What will happen if someone tries to measure a file larger than this limit? What's the failure mode? Cheers, Dave. -- Dave Chinner david@fromorbit.com