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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B512CD54BF for ; Tue, 19 Sep 2023 11:56:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 731756B0501; Tue, 19 Sep 2023 07:56:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E0DE6B0502; Tue, 19 Sep 2023 07:56:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A8326B0503; Tue, 19 Sep 2023 07:56:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4548C6B0501 for ; Tue, 19 Sep 2023 07:56:55 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 139161A0D9D for ; Tue, 19 Sep 2023 11:56:55 +0000 (UTC) X-FDA: 81253195590.26.1732549 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf30.hostedemail.com (Postfix) with ESMTP id 4B5EE8001F for ; Tue, 19 Sep 2023 11:56:53 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YHFTrtap; spf=pass (imf30.hostedemail.com: domain of ritesh.list@gmail.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=ritesh.list@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695124613; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:in-reply-to:references:dkim-signature; bh=mNmSIzeXuu0W8Adeux1YMe2sJA/HQO2+qwmQbYj25qQ=; b=caozAeQlsDonXR12Bxqiw1guc+Qsy+PrBG8wdg71nlyACpfmzFprvbKB3UyM87AhS2yXUe F+YA8Pf6R4nV1RnPdtGCKkiE6LE7M04m2ns/ZQvnMnE9H+87gXHpp85UPETPVGsBLuvrdz 1FEGVRZ/qlEcER/B0Udue7dBDJd11sU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YHFTrtap; spf=pass (imf30.hostedemail.com: domain of ritesh.list@gmail.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=ritesh.list@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695124613; a=rsa-sha256; cv=none; b=WKv6EX0PF/TXLFUErvRiW2+Pc3YFOvWRoMwSUCKm8iJB5BwuDITyHkV8/OXb+XSgaPDd4F AEeScc4dflzJY26/Cs9BU/xrAN8W2drw42dSauhEe9GHoBeJ3d3rZ270CWAaSISJGHdLaO 0/h9Miqq69V58d7RMgQ8I3IHneoE+oU= Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1c337aeefbdso52105895ad.0 for ; Tue, 19 Sep 2023 04:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695124612; x=1695729412; darn=kvack.org; h=in-reply-to:subject:cc:to:from:message-id:date:from:to:cc:subject :date:message-id:reply-to; bh=mNmSIzeXuu0W8Adeux1YMe2sJA/HQO2+qwmQbYj25qQ=; b=YHFTrtapbHw/IMD/GEHYZ3flC78AoXK5m+bomCaYqr9BY4Kob5osqz3JenZNW/Tal1 LhVVtHxTu3VfFU630bYK93fI02A2vZmI1YlNR0kMxaYT3VrPO+iaSyb7OV10+Bs0fuYh 1AvD84ggU1QZpUNjQHUwIu45PoL3Em7KDZZa/n1CwBmYhLe26c5Q6EFKia12V4CqoYvz rIWemcfIHYkMcFjxkDE9wdQkRc1nJZbsGPBFq9L/4XeCa7ddqk/oGsQSAD5rEHjOwOEz vhc1z/h3LNhov4F0fxoslwWcrfOn2zKpt+aETqUyFbZeb1Msn5MQG0z+z1Hk6FeGDciD SOTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695124612; x=1695729412; h=in-reply-to:subject:cc:to:from:message-id:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=mNmSIzeXuu0W8Adeux1YMe2sJA/HQO2+qwmQbYj25qQ=; b=SoJL9aKJrvEIvMLpb2Nq01WTGra/ijJarLedl05DN7Lyw4pbAZ0A1cP2Krkh2Yxxl4 x65g5dcb3GiXcX3Mi7KFKIpXjTG+sDscUSzlaJgZkemwt2Ju7KNZVifs8E+pagRw5dAW TxdgScyPA27EtngKj00M5OTB6LVTZuQ7tp9UCYysPrHiHytr2O9BnEvGbSqasau8Lmf+ n+cnTXrd6mapKSt4dtveGvxJOzBOLU6SuTEsaREShwGrvbtWyP9q+BafOgqLrmKozgFV tYOoVG6CcYxB5zh/L+zrYFab1OP8H/TMvzZEZkHeSZMzlP51G4w0rKv3R1s7Er5AgHwl sseg== X-Gm-Message-State: AOJu0YxK59fR8QtgMEkR9QEwjdEItX+KpQlv2zwuzHHG5TystlbLW2z7 JLwspdC+f35tNr0lM+BsBLU= X-Google-Smtp-Source: AGHT+IGkeb0dGVTQ5tbZ8aAKLi7LkUBg6Enozcwq82i6LIXi74JZeDiB+v3dbMvqJRrINh4lA8ivHg== X-Received: by 2002:a17:903:2301:b0:1b8:b285:ec96 with SMTP id d1-20020a170903230100b001b8b285ec96mr14864303plh.23.1695124612041; Tue, 19 Sep 2023 04:56:52 -0700 (PDT) Received: from dw-tp ([49.207.223.191]) by smtp.gmail.com with ESMTPSA id c21-20020a170902c1d500b001bb8895848bsm3746960plc.71.2023.09.19.04.56.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 04:56:50 -0700 (PDT) Date: Tue, 19 Sep 2023 17:26:44 +0530 Message-Id: <87a5ti74w3.fsf@doe.com> From: Ritesh Harjani (IBM) To: Pankaj Raghav , Dave Chinner , Luis Chamberlain Cc: Pankaj Raghav , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, da.gomez@samsung.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, willy@infradead.org, djwong@kernel.org, linux-mm@kvack.org, chandan.babu@oracle.com, gost.dev@samsung.com, riteshh@linux.ibm.com Subject: Re: [RFC 00/23] Enable block size > page size in XFS In-Reply-To: <806df723-78cf-c7eb-66a6-1442c02126b3@samsung.com> X-Rspamd-Queue-Id: 4B5EE8001F X-Rspam-User: X-Stat-Signature: ye6a97ehwh7ojcykbou7cmm84z4m1p9w X-Rspamd-Server: rspam01 X-HE-Tag: 1695124613-357766 X-HE-Meta: U2FsdGVkX18Uo4RnC+lY1ss3E79Seg7FE0GOyRTkKYnJAadRmYvZ+s4PBO1+9FxSX85o9wMfSLzNr28IdL8McZrraTG7EgF4TFAVJ9LF56MQSbouVaEIm1NPQahT5BrxXNsP+MHM42x6w7KXYcC4crkE3rG9VhSG8rJgDACcSjmQ5hup/KBKe9CgzRv1JuUGm6NreyF1Yq2OffodhaVBwai5wxSPNpvv6yDukiEWkDqkuj7+IC5ECf/4+qjb3jDvWkfFdLWf0dhJ0HlZ7CM40Pi9bqQcjyc5aWeozDmSoFLyy/qA0xDKOUdG+HWGlAd32Z80kcCUJN3JeUmpShfI67N//RLFeV+cvmFWaS88DXJ0FsdkvaP3lNyZRr8eOyV5NSBGdhkq80yacwmAvmcGdE/CRSk78uAg1O0F2DX1ojynnaGY2fZ3wZURb6F381tC+zymzEOs2Zv7k6aWjbz9/GfzhDjAq7d2Tgj6K1ucJgKkmlNwnHHHA/huuZOv0qRTTZ1yWDczcHWQiTZXKi4QmPUqrk5yThH83SbOTJvdFkkxSm8BV6I7/ZQLZzoXuPmDwyAB49LxjgS72U0FtT2KfTIbtNswJ7C/ypi5HJ6qGcxUrmYIatHnD7qe/degmlYrTYqiCVq2zmxA9wymbZUURXLSVmQfeu58mThMro2TRaVWUze2uiIRoyBSIqTIIpoIESq6+nd/+GGfX67j87IQQmhoYIi8wLDb8p/nbFaGeRTVw4Rt9nVGX3MlMQ+g652rzQw1AIZps/gt2oHu+fmjMJu7tkMV3+Fy7x4GUPcMV+y1TjdtZ82TsFa/MrNFT/a75Wsg8rL5rqcIGLnfm+nRSVXRf9Ds3vET//8M6MN3CKu8osKwCIs5PQQwjZ9HIKa9qs/gFco6JjNmjP+usR/VbdGT8GYFFEIvgUaNMQTc3Jb9n0ZMSNma1FQdpr8eBt/sUg21Bp6I2CRbDsEHT0S HyguRYF5 4Fg123Y8inZnwfNUE9CIJP+ZQiB261DpMzxn16U1yKjy4sQoQBo3h0jmaVRok1Weqp1izZyMsCuKsVpx2r4wh+hNV/8Jrfgku6Rlp/LJKaFqeADgw+GyG1HGz6ZoxLzxtADEsY8Uuvs0B5Ik1P992lidYbWx2PSta9cX537s5L5Ie8OZasJrwY9v+XEcwCAqNSRa1dQmQfkTU399M8mfgmqK8I6RLZ7u0X0EA/swLpzzFMSNlM/vuCzumGY7GKNWfA9Wpx9xUmKe2ipZ4wZU5WfwWPWtS+d/yka+isgqamMrnN34y6jTl5sKajqIstehG7AeZIHUcSXA15+WjjWHDe8ShnhFXupi8r2lalyqr78WFUUnHQ4YfvPWLLcdzKvP/P2RjqrHxnRq0/LaoexaZqwKxzeJXf4sFhgXO2HPemzjhz3yKeC6mneJpG2cLNrsJTBeKiyo7AXeL2695Bb73ymrjdrNYXtqYxgw7z5Xg8jnPWN+qj0I7HuyfJRFsE81dko86 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Pankaj Raghav writes: >>>> >>>> As it is, I'd really prefer stuff that adds significant XFS >>>> functionality that we need to test to be based on a current Linus >>>> TOT kernel so that we can test it without being impacted by all >>>> the random unrelated breakages that regularly happen in linux-next >>>> kernels.... >>> >>> That's understandable! I just rebased onto Linus' tree, this only >>> has the bs > ps support on 4k sector size: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=v6.6-rc2-lbs-nobdev >> > > I think this tree doesn't have some of the last minute changes I did before I sent the RFC. I will > sync with Luis offline regarding that. > >> >>> I just did a cursory build / boot / fsx with 16k block size / 4k sector size >>> test with this tree only. I havne't ran fstests on it. >> >> W/ 64k block size, generic/042 fails (maybe just a test block size >> thing), generic/091 fails (data corruption on read after ~70 ops) >> and then generic/095 hung with a crash in iomap_readpage_iter() >> during readahead. >> >> Looks like a null folio was passed to ifs_alloc(), which implies the >> iomap_readpage_ctx didn't have a folio attached to it. Something >> isn't working properly in the readahead code, which would also >> explain the quick fsx failure... >> > > Yeah, I have noticed this as well. This is the main crash scenario I am noticing > when I am running xfstests, and hopefully we will be able to fix it soon. > > In general, we have had better results with 16k block size than 64k block size. I still don't > know why, but the ifs_alloc crash happens in generic/451 with 16k block size. > > >>> Just a heads up, using 512 byte sector size will fail for now, it's a >>> regression we have to fix. Likewise using block sizes 1k, 2k will also >>> regress on fsx right now. These are regressions we are aware of but >>> haven't had time yet to bisect / fix. >> >> I'm betting that the recently added sub-folio dirty tracking code >> got broken by this patchset.... >> > > Hmm, this crossed my mind as well. I am assuming I can really test the sub-folio dirty > tracking code on a system which has a page size greater than the block size? Or is there > some tests that can already test this? CCing Ritesh as well. > Sorry I haven't yet looked into this series yet. I will spend sometime reading it. Will also give a spin to run the fstests. But to answer your question on how to test sub-folio dirty tracking code[1] [2] with XFS. Just use blocksize < pagesize in mkfs option and run fstests. There are a no. of tests which checks for data correctness for various types of writes. 1. test 1k blocksize on a 4k pagsize machine (as long as bs < ps) 2. Test 4k blocksize on a 64k pagesize machine (if you have one) (as long as bs < ps) 3. Or also enable large folios support and test bs < ps (with large folios system starts insantiating large folios > 4k on a 4k pagesize machine. So blocksize automatically becomes lesser than folio size) You will need CONFIG_TRANSPARENT_HUGEPAGE to be enabled along with willy's series which enables large folios in buffered write path [3]. (This is already in linux 6.6-rc1) /* * Large folio support currently depends on THP. These dependencies are * being worked on but are not yet fixed. */ static inline bool mapping_large_folio_support(struct address_space *mapping) { return IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && test_bit(AS_LARGE_FOLIO_SUPPORT, &mapping->flags); } [1]: https://lore.kernel.org/linux-xfs/20230725122932.144426-1-ritesh.list@gmail.com/ [2]: https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/commit/?h=for-next&id=4ce02c67972211be488408c275c8fbf19faf29b3 [3]: https://lore.kernel.org/all/ZLVrEkVU2YCneoXR@casper.infradead.org/ Hope this helps! -ritesh