From patchwork Thu Oct 17 19:03:39 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13840693 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DD07219CA6; Thu, 17 Oct 2024 19:03:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729191820; cv=none; b=qFvlaXEN4ft6+blfD3twp3/bKcDfOygLSyREdYVX21Re+4dKccGuPeZVwZgEpgdpktGnLs8IA0OJ+3kY7VXouyFGAqSZIQGMRvlS2C69FUTmGkmTIPMkWskisDM0FwqXDJ5VTTpsV8EfjpKgkwWnjnE6eBC5fzwc/AML4okq07Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729191820; c=relaxed/simple; bh=RTUzcOj1zOkR/wRkPpifiR9ZrN2kO5e4mfFr7auibZ8=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SwF6g/03VKAmhUAbqC/L3IpF0t3hRt4UmcEPr1eAFfQPmZOFkGRaZnE8IcuA88vYC+FOEDZ8wDUy0WinjCY24ZHdhOjNXRlLVJkWEk1Vm+e2K8gt1NCxTblz7V94w+GhioFe9QbnxHpyUD3Yns42XxFgHMLnOB/d22TtFjK6J2k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V3ROzXtC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V3ROzXtC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C45FC4CEC3; Thu, 17 Oct 2024 19:03:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729191820; bh=RTUzcOj1zOkR/wRkPpifiR9ZrN2kO5e4mfFr7auibZ8=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=V3ROzXtCn+7fz1+JBEtt9a63is/F8uRtLig5kPJkBHnN/DWSiNxxXAHwpuJVVp1v0 R40DpkZqCdqaRNfO54qIawc6u3TL1i4+/k0OUtcL26LvhVFlQ8T3PeJS2tq8knkPbj NjYmih0jCsUK8Eb1GLffZeFUYowgioIO8rEPHQty4R+U/+3gmDSsgFhN2spXzXlqnm XkzfqDd5LtV7Lb4uIg7C9UTOUInuCQJlOo75S9uB+HVF3lhK0J9dQ5LgnS0eUrtAAk flbBU7mVpOg+skMFOngPJ88PPAY5KqRVV2RaISumYQ5tBXLr7h0+yeTu1RBe3R4RLh VdtKgQTORrq+g== Date: Thu, 17 Oct 2024 12:03:39 -0700 Subject: [PATCH 1/2] xfs: fix rt device offset calculations for FITRIM From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de, linux-fsdevel@vger.kernel.org Message-ID: <172919071131.3453051.3024728895345414372.stgit@frogsfrogsfrogs> In-Reply-To: <172919071109.3453051.9492235995311336058.stgit@frogsfrogsfrogs> References: <172919071109.3453051.9492235995311336058.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong FITRIM on xfs has this bizarro uapi where we flatten all the physically addressable storage across two block devices into a linear address space. In this address space, the realtime device comes immediately after the data device. Therefore, the xfs_trim_rtdev_extents has to convert its input parameters from the linear address space to actual rtdev block addresses on the realtime volume. Right now the address space conversion is done in units of rtblocks. However, a future patchset will convert xfs_rtblock_t to be a segmented address space (group:blkno) like the data device. Change the conversion code to be done in units of daddrs since those will never be segmented. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- fs/xfs/xfs_discard.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/fs/xfs/xfs_discard.c b/fs/xfs/xfs_discard.c index 4f3e4736f13ea6..42b8b5e0e931b7 100644 --- a/fs/xfs/xfs_discard.c +++ b/fs/xfs/xfs_discard.c @@ -480,7 +480,7 @@ xfs_discard_rtdev_extents( trace_xfs_discard_rtextent(mp, busyp->bno, busyp->length); error = __blkdev_issue_discard(bdev, - XFS_FSB_TO_BB(mp, busyp->bno), + xfs_rtb_to_daddr(mp, busyp->bno), XFS_FSB_TO_BB(mp, busyp->length), GFP_NOFS, &bio); if (error) @@ -612,22 +612,25 @@ xfs_trim_rtdev_extents( xfs_rtblock_t start_rtbno, end_rtbno; xfs_rtxnum_t start_rtx, end_rtx; xfs_rgnumber_t start_rgno, end_rgno; + xfs_daddr_t daddr_offset; int last_error = 0, error; struct xfs_rtgroup *rtg = NULL; /* Shift the start and end downwards to match the rt device. */ + daddr_offset = XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks); + if (start > daddr_offset) + start -= daddr_offset; + else + start = 0; start_rtbno = xfs_daddr_to_rtb(mp, start); - if (start_rtbno > mp->m_sb.sb_dblocks) - start_rtbno -= mp->m_sb.sb_dblocks; - else - start_rtbno = 0; start_rtx = xfs_rtb_to_rtx(mp, start_rtbno); start_rgno = xfs_rtb_to_rgno(mp, start_rtbno); + if (end <= daddr_offset) + return 0; + else + end -= daddr_offset; end_rtbno = xfs_daddr_to_rtb(mp, end); - if (end_rtbno <= mp->m_sb.sb_dblocks) - return 0; - end_rtbno -= mp->m_sb.sb_dblocks; end_rtx = xfs_rtb_to_rtx(mp, end_rtbno + mp->m_sb.sb_rextsize - 1); end_rgno = xfs_rtb_to_rgno(mp, end_rtbno); From patchwork Thu Oct 17 19:03:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13840694 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0147E1DED44; Thu, 17 Oct 2024 19:03:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729191831; cv=none; b=rKOeQskGj9oB5PVTcfkvmjFGbqwESiGGJbXadxgtKM4hPve4jhj+0X0+2/tgPyZHnjLYw9hG8/YBttBLAIATiIljYsL0VHIu8N1weNLKCk41p+4+Ub1FfWl/ic3FwyLiywb4wbzb7uwE1e0IY9tTHkGRiL5o4OUjSiBaMVwgqXg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729191831; c=relaxed/simple; bh=Qt/5hlRql92AK1Nma6sI6o8MPxQ98DvyWnPnZ61x8VE=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uzA5fxnCeSa2TJ8WQj9M/JysmUUTZviXmfX/LgQkQ+s9x6aO9SDtgCGhxQdOBoRSUaD11YEN7CBr+/lsN9XWJzu5QvnTrsiaZnpmR80yu1IwgWfW0qrl3z1VTVt7Vl6J+tNa63TWcRUqPSEwdni3c34eFTC66YSqyDA0Ky8iMMo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=b0PD6Yb/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="b0PD6Yb/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C74B2C4CEC3; Thu, 17 Oct 2024 19:03:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729191830; bh=Qt/5hlRql92AK1Nma6sI6o8MPxQ98DvyWnPnZ61x8VE=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=b0PD6Yb/kGZKA4Pp85CrQdgGzqhy+6qc/nPApldtKb75Q1gIuRlgvGOBMf8HrMv4W E1c9xSp3eIVRVnXUTim/32T8nfbevgbUY/vKcWm4Wz4QEKeEuOfEVYK6xYX+U0aX+1 Vw64uv2hG9JoFXVeOvtrto4zo0o7yIrzYggzo2n87eq8Sn0OiXwfWFCFZPKtUvbuC9 STOuuBPgPxtCfWmt/vQZpuQbMY1KkI3yqv3i70KsRucYHg/8RY2b4ky6K4TdnM/Tgq 6dK5l3F5WKqY4TRXchln4eC4tSITIsrMYH1SbRgKfVE1erggDMDU1Mg78Sf3Gk0FaU NwGN9IULql2PQ== Date: Thu, 17 Oct 2024 12:03:50 -0700 Subject: [PATCH 2/2] iomap: add a merge boundary flag From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de, linux-fsdevel@vger.kernel.org Message-ID: <172919071148.3453051.9835175294057528187.stgit@frogsfrogsfrogs> In-Reply-To: <172919071109.3453051.9492235995311336058.stgit@frogsfrogsfrogs> References: <172919071109.3453051.9492235995311336058.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christoph Hellwig File systems might have boundaries over which merges aren't possible. In fact these are very common, although most of the time some kind of header at the beginning of this region (e.g. XFS alloation groups, ext4 block groups) automatically create a merge barrier. But if that is not present, say for a device purely used for data we need to manually communicate that to iomap. Add a IOMAP_F_BOUNDARY flag to never merge I/O into a previous mapping. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong --- fs/iomap/buffered-io.c | 6 ++++++ include/linux/iomap.h | 4 ++++ 2 files changed, 10 insertions(+) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 3899169b2cf733..6f7691ef1e4164 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -1657,6 +1657,8 @@ iomap_ioend_can_merge(struct iomap_ioend *ioend, struct iomap_ioend *next) { if (ioend->io_bio.bi_status != next->io_bio.bi_status) return false; + if (next->io_flags & IOMAP_F_BOUNDARY) + return false; if ((ioend->io_flags & IOMAP_F_SHARED) ^ (next->io_flags & IOMAP_F_SHARED)) return false; @@ -1776,6 +1778,8 @@ static struct iomap_ioend *iomap_alloc_ioend(struct iomap_writepage_ctx *wpc, INIT_LIST_HEAD(&ioend->io_list); ioend->io_type = wpc->iomap.type; ioend->io_flags = wpc->iomap.flags; + if (pos > wpc->iomap.offset) + wpc->iomap.flags &= ~IOMAP_F_BOUNDARY; ioend->io_inode = inode; ioend->io_size = 0; ioend->io_offset = pos; @@ -1787,6 +1791,8 @@ static struct iomap_ioend *iomap_alloc_ioend(struct iomap_writepage_ctx *wpc, static bool iomap_can_add_to_ioend(struct iomap_writepage_ctx *wpc, loff_t pos) { + if (wpc->iomap.offset == pos && (wpc->iomap.flags & IOMAP_F_BOUNDARY)) + return false; if ((wpc->iomap.flags & IOMAP_F_SHARED) != (wpc->ioend->io_flags & IOMAP_F_SHARED)) return false; diff --git a/include/linux/iomap.h b/include/linux/iomap.h index d8a7fc84348c4d..d44c982085a39f 100644 --- a/include/linux/iomap.h +++ b/include/linux/iomap.h @@ -53,6 +53,9 @@ struct vm_fault; * * IOMAP_F_XATTR indicates that the iomap is for an extended attribute extent * rather than a file data extent. + * + * IOMAP_F_BOUNDARY indicates that I/O and I/O completions for this iomap must + * never be merged with the mapping before it. */ #define IOMAP_F_NEW (1U << 0) #define IOMAP_F_DIRTY (1U << 1) @@ -64,6 +67,7 @@ struct vm_fault; #define IOMAP_F_BUFFER_HEAD 0 #endif /* CONFIG_BUFFER_HEAD */ #define IOMAP_F_XATTR (1U << 5) +#define IOMAP_F_BOUNDARY (1U << 6) /* * Flags set by the core iomap code during operations: