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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 5F9E1C43603 for ; Mon, 9 Dec 2019 10:21:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 319DA20828 for ; Mon, 9 Dec 2019 10:21:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IEzijxr3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727379AbfLIKVU (ORCPT ); Mon, 9 Dec 2019 05:21:20 -0500 Received: from mail-qk1-f194.google.com ([209.85.222.194]:39052 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726377AbfLIKVU (ORCPT ); Mon, 9 Dec 2019 05:21:20 -0500 Received: by mail-qk1-f194.google.com with SMTP id c16so4132805qko.6; Mon, 09 Dec 2019 02:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5wpZqct9zId1JMwIvIkTx98tJap0IvMG3KRrK6bEBDM=; b=IEzijxr3E1MusXczAG2YYKgDDebdtwecdNChK8m0OZEuPTczGvG/jF8TIAj6eRHJbn zGKRwTp/VOf6TQ4y52WYJZaFpC2mXgQTNWw/cQEdlOdzNkkuG3OkrE/taG3vtua5mPQx vzXPMmV9ks6Nu8rrxwjMFew9TrRekYdQyaS5uz9nvWnjyt0lNHOImUh5uWPYcCKqYr6O Ftvijxlneg7V9vTHmu3cGwn5idi4FUap9nZnjbartbHGqUgkBWWCm5lfdPe5mBZSolt2 KYajD2UnoEgw+wCTLOUGik1/3aob3g4MwpOJIbC76wuF/ZlEKrd+bhwdWVoIucJu+RK3 M8bQ== 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:content-transfer-encoding; bh=5wpZqct9zId1JMwIvIkTx98tJap0IvMG3KRrK6bEBDM=; b=VMyvf86C8yJG+xn7gWOOdzghPOXXf2mQK68UzoBFQFugfCHM7VVXVka1+3+gnhr4gN LjBoNNVfO0VUPgBL4X2RA0q1kWCrJpxX8SOHVuQJEw+Rmt/MHtdhVhOlKz2qnfU6tGqh XhdEyEEhMgCl7SRdjxfzLvTyR8BSNahiuluxZc/LLd2Bz3+bwcEMLo8ILaObiIrDWUrh oXP3dppHw6kMcd4uSidZz9sMKnQMAVkLKvtzepxbv/R/WK1Y12YK7XSRE8VggLteblAT pmxifBVhSzBBlAWHRNX1iT6wIkJ4fyXJnqulfvqKR0FQfIVbHJTbzkHSN46iS6PMF4zx J8kw== X-Gm-Message-State: APjAAAWUDsh12UFZWCB8705dCu2h7f25tduqg6xyFWVvh1dZXq+0HsgM HVWxj1rSm528lQ143QQtyxI4oVH0ubHXook9QWI= X-Google-Smtp-Source: APXvYqyiNlRqsKmdsEqcVQgML3WflGAH6cHuImDpuJGUsALxjPRXGR5VclsRP4zcDT20/Ag5ILjgKv74utoPsvlBGKg= X-Received: by 2002:ae9:e30e:: with SMTP id v14mr25857560qkf.344.1575886878939; Mon, 09 Dec 2019 02:21:18 -0800 (PST) MIME-Version: 1.0 References: <1575622543-22470-1-git-send-email-liangchen.linux@gmail.com> <1575622543-22470-2-git-send-email-liangchen.linux@gmail.com> <20191209073744.GB3852@infradead.org> In-Reply-To: From: Liang C Date: Mon, 9 Dec 2019 18:21:07 +0800 Message-ID: Subject: Re: [PATCH 2/2] [PATCH] bcache: __write_super to handle page sizes other than 4k To: Coly Li Cc: Christoph Hellwig , Kent Overstreet , linux-kernel@vger.kernel.org, linux-bcache@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org No problem. I will change the patch to remove this extra read. Thanks. On Mon, Dec 9, 2019 at 5:52 PM Coly Li wrote: > > On 2019/12/9 3:37 =E4=B8=8B=E5=8D=88, Christoph Hellwig wrote: > > On Fri, Dec 06, 2019 at 05:44:38PM +0800, Coly Li wrote: > >>> { > >>> - struct cache_sb *out =3D page_address(bio_first_page_all(bio)); > >>> + struct cache_sb *out; > >>> unsigned int i; > >>> + struct buffer_head *bh; > >>> + > >>> + /* > >>> + * The page is held since read_super, this __bread * should not > >>> + * cause an extra io read. > >>> + */ > >>> + bh =3D __bread(bdev, 1, SB_SIZE); > >>> + if (!bh) > >>> + goto out_bh; > >>> + > >>> + out =3D (struct cache_sb *) bh->b_data; > >> > >> This is quite tricky here. Could you please to move this code piece in= to > >> an inline function and add code comments to explain why a read is > >> necessary for a write. > > > > A read is not nessecary. He only added it because he was too fearful > > of calculating the data offset directly. But calculating it directly > > is almost trivial and should just be done here. Alternatively if that > > is still to hard just keep a pointer to the cache_sb around, which is > > how most file systems do it. > > > Copied, if Liang does not have time to handle this as your suggestion, I > will handle it. > > Thanks for the hint. > > -- > > Coly Li