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 BAD76CE79AD for ; Tue, 19 Sep 2023 21:15:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 574266B00DB; Tue, 19 Sep 2023 17:15:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 524196B00DC; Tue, 19 Sep 2023 17:15:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4137C6B00DD; Tue, 19 Sep 2023 17:15:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 32B026B00DB for ; Tue, 19 Sep 2023 17:15:48 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EF6A7405E2 for ; Tue, 19 Sep 2023 21:15:47 +0000 (UTC) X-FDA: 81254603934.12.9028A95 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf24.hostedemail.com (Postfix) with ESMTP id D8FDF18001F for ; Tue, 19 Sep 2023 21:15:44 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="boUnKA/K"; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf24.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695158145; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SoWGV/vSjH+QSAal7RVjoWtaY6GPfVPJsY2HI1Po9NA=; b=5b/cz3Ry1fM78+8JUcOB0gLLdjYNapnuH8Ulzf9KeS60Qv1282RT7DXrMchUDX6WYY9ZqF F9EjpReRAfELhGVlv9Kz/7gM395fdCZhcKZrbsN3aciBYJjxNEHOm2TU9i2VsgpZFxHqvQ DCeG/SUifwa/HmMomqIKSF9Byaxc5jU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="boUnKA/K"; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf24.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695158145; a=rsa-sha256; cv=none; b=v5dHDDzOWw39ecknzdc2HXl58N9I1xCIcS5x8Rd5pPPgSIPJ+/H6Vj4luMbR2EhVKV2oQh 0ZyYgiYziO58Al8+xc1MSKmnU2I/WrP6fsLOxTdjrvRTTl9yEV95QsLKlsJY7uHtfsGwVZ kLznol/WZmPdqK0DLG9BuBW3TJMbzwQ= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=SoWGV/vSjH+QSAal7RVjoWtaY6GPfVPJsY2HI1Po9NA=; b=boUnKA/KWwv2o53fF2DYhZzJHW 0f6aI76KTdV20mN53VyMRh3dCbFxTwr5RHi976RJMoVrluOyoyaeMvRTSJaeOHQSVqHO3fxsGIBr/ ae5hxtKmlTSk/1427oc6gFk5U0uNbFKfMJ322QqhXWMf0tyLUqnjCWzHa0jHypGgOnnmRlMMP2MW9 7672V8UtKVY6hCn5dhC+ysO2QHjqCfubvuMFx0QIs+0jI3mlwRBjtis0socm0RWiXpXtNjW2RlqqI jqCi7+sEIjUq/xl4R2sLRm2BBcpy5rJ9rycLkFNSliv0s4fkNvpbB1+AbkLPNydAD8xvPMlGLvWO6 hoMXSL8w==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1qii4E-001HO9-1Y; Tue, 19 Sep 2023 21:15:34 +0000 Date: Tue, 19 Sep 2023 14:15:34 -0700 From: Luis Chamberlain To: Ritesh Harjani Cc: Pankaj Raghav , Dave Chinner , 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 Message-ID: References: <806df723-78cf-c7eb-66a6-1442c02126b3@samsung.com> <87a5ti74w3.fsf@doe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a5ti74w3.fsf@doe.com> X-Rspamd-Queue-Id: D8FDF18001F X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 7q8fcycguw87oqw9yrpc9r9re5rzk3tz X-HE-Tag: 1695158144-555318 X-HE-Meta: U2FsdGVkX1+SpqIp01vWVVlXR5J9fEce/eNTfK+HmEsm3uSfjL83RlR6c1LsD2QUWEp3yv0XiAKjozjeWaRiQ0gcCD2H+20xpjpY0KFCe0wkx2A1B27zqz9S4YpMAUR2xkz74y/x097krsl8fbvjaBmTZHD5PNEJC55LhAZhG5hPS46Ky2v6vMA+41LVg6tuYl6GtsYaRr+XBo1VmP/7xw45T55dUneQ2zxTfixd4XiF0RFBtFK4q+9ne3fcXSMGxzg8OkeuF7VjDjSg2KROfSeLOxU5gY0GdWrkSaxM3w6L+edyO8JYtapVhSqZtGY6bKCcOZTQr7fm9Sc5gVQVRGwFecSG880EXBDITvFstI+5WvgYhiJOC3MICab618P+L/uezFzGuZq3SGtCvf3zffl/Ced89AiemGZdgwPVZhxD/YaJ5gWcvkO15hKj/+jItDTl23Mjk3JJPh4FCFZO73hZ4IY3II6zI+hOXx9FQWdsIxe2weYG6mDIOeAjEgNidTqAS0LTolyNp+otnyOD023d04L9fJUViMRaIFrvJYnjtjPjfjdDpLvW5GJmhekvuKkjgSlTXZztwe3WnOWAP5gSFEDj+n1ua5S/ar8ujHkKkejLsWdY5QSA+vpjndoxm5vv+mVqjh/Jv7CSlREPd6vjgA2y5SjYwr9kkzeZbGL5hbl54cJylWfKrfkw+Cr0SETs66ETdE3dzQCY73+atNUtpRyQwCwZIS5NeWwEt17omZMAMb/9VEDd1q/7b1zI0dE5Zs4eh1G/jBkAvD6HBv0wEydAy4PtB+4lc7hxxhHBe4XovAEw8iGy3zMZEMTy1OoegGnhbuBH8Wu++W32URTGmRca0iAKN2UhdVICESEkl7hWRZn2wWKznCr6otayfDhUTJ428JP7SKWy5u2/qMSo3eM5w7BeqB39XTMWqdXiGQH9iOOtJP8by6BXTyVksP8vxAelMJNKGefdhHJ l8yc9kYk 1u+O25AqHOG0VJR7WFgQsbuZ//9G0clSFPEpwqkpEEtRRwwPfCsDR0KNDxm+T3Cm+F6IaBARoSWszf1Kzdu3UAax9lWJWvy9H1t20mBJNvwPc21cSEJ3IxYnHI6hGv7BZ7qaDoJOnlR3VcK4yRdC4JeIDJVTZKLFwN7mRB3pHWNnx05nGG2XdTUf/3hL2zCHZMO+VFT9DGZ+v5m+vzfk6uzvGWKJkzvTu4hBMOhuHebfB6M32k1Lr9WNyNRsRYt3VProOIQXluwjAmwliqcod7qO5BEM9Kuo86vIog88zwS+SSPFm9IVbej/pU+VvcR2zLBmscov45FNBxHxumZU3rjl7t2ZZQJljVQrPaR2l/On9hBMOGVOxOzPT/+EUTcjkjL2QkncFQxzSmOxjJJSCR7jZ0/Bz42Ws59yW357ye0Op4aSossOFgSoDSpOZtt5bT5hmESqGYqogNUQ= 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: On Tue, Sep 19, 2023 at 05:26:44PM +0530, Ritesh Harjani wrote: > 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. Ritesh, You can save yourself time in not testing the patch series with fstests for block sizes below ps as we already are aware that a patch in the series breaks this. We just wanted to get the patch series out early for review given the progress. There's probably one patch which regresses this, if each patch regresses this, that's a bigger issue :P Luis