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 C2A61EB64DA for ; Sat, 8 Jul 2023 04:11:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232741AbjGHELC (ORCPT ); Sat, 8 Jul 2023 00:11:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229751AbjGHEK6 (ORCPT ); Sat, 8 Jul 2023 00:10:58 -0400 Received: from out-26.mta1.migadu.com (out-26.mta1.migadu.com [95.215.58.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A6A71FEA for ; Fri, 7 Jul 2023 21:10:56 -0700 (PDT) Date: Sat, 8 Jul 2023 00:10:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1688789454; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Tua3cusTVAWiQUobwnIpJERruf3dwUSDMjP59oVXpbA=; b=GPa5oZizFI9+msR4SXLzcoMgJkBvTt+D93ZbTGPMlJAQMpdoXXkgJLUbYSbxtydyJAa9pX 9pjJuFDCzcishQaHaAJxvNiBs9GX0r+Opp8+kSD8NI4zmpCHaOtaxGhyMHN/ZVrFYCmCjm WriBPdv1lp+dEH+swlj8FNXEi6ULiIs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Matthew Wilcox Cc: James Bottomley , Christian Brauner , "Darrick J. Wong" , Josef Bacik , torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-bcachefs@vger.kernel.org, dchinner@redhat.com, sandeen@redhat.com, tytso@mit.edu, bfoster@redhat.com, jack@suse.cz, andreas.gruenbacher@gmail.com, peterz@infradead.org, akpm@linux-foundation.org, dhowells@redhat.com Subject: Re: [GIT PULL] bcachefs Message-ID: <20230708041049.2tdw6fnnjtqwuqlw@moria.home.lan> References: <20230626214656.hcp4puionmtoloat@moria.home.lan> <20230706155602.mnhsylo3pnief2of@moria.home.lan> <20230706164055.GA2306489@perftesting> <20230706173819.36c67pf42ba4gmv4@moria.home.lan> <20230706211914.GB11476@frogsfrogsfrogs> <20230707-badeverbot-gekettet-19ce3c238dac@brauner> <20230707091810.bamrvzcif7ncng46@moria.home.lan> <30661670c55601ff475f2f0698c2be2958e45c38.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 08, 2023 at 04:54:22AM +0100, Matthew Wilcox wrote: > One thing I particularly like about btrfs :) > compared to ntfs3 is that it doesn't use old legacy code like the buffer > heads, which means that it doesn't add to the technical debt. From the > page cache point of view, it's fairly clean. I wish it used iomap, but > iomap would need quite a lot of new features to accommodate everything > bcachefs wants to do. Maybe iomap will grow those features over time. My big complaint with iomap is that it's still the old callback based approach - an indirect function call into the filesystem to get a mapping, then Doing Stuff, for every walk. Instead of calling back and forth, we could be filling out a data structure to represent the IO, then handing it off to the filesystem to look up the mappings and send to the right place, splitting as needed. Best part is, we already have such a data structure: struct bio. That's the approach bcachefs takes. It would be nice sharing the page cache management code, but like you mentioned, iomap would have to grow a bunch of features. But, some of those features other users might like: in particular bcachefs hangs disk reservations and dirty sector (for i_blocks accounting) off the pagecache, which to me is a total no brainer, it eliminates looking up in a second data structure for e.g. the buffered write path. Also worth noting - bcachefs has had large folio support for awhile now :)