From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 30E1526ACC; Sat, 11 Jul 2026 00:24:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783729456; cv=none; b=mL7VshNCe+UzG5WxYFXGEeFv5p13A8C7qSPXnGPWbcAbEyGO1R9dR/TMoJjlIpXnzzrPZ4y0uhPu7qap9tBFFolJUfVyHqksmvfdbl1gAPsyjsoCoUmUEObHMfibTUMX2PEfIEx+/XRaqqd3kA6EbVrIQuJP0uTAmnwUsue8D5Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783729456; c=relaxed/simple; bh=pwcS+JPhE+W/ODtU0qbehIRMPyrOXRiZ+yUqfS2Rkho=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Kp1kpEyf/fkzsUQy/SmNvoAZQAUHjk9Oepc9edfKRUf+qBPxvn1huWFsu6MlRzPSPb9KaLfkDMSjfCtobfo4TCDbCfaUMAWFelyxBZmbe/IYTf5dzjvdTyzHMUY7ubyrIeHxkJmmwWAfCXN+935DT088TH6KYlE5BDW+23fUDlA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=POsAX31I; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="POsAX31I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC45D1F000E9; Sat, 11 Jul 2026 00:24:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783729454; bh=KFEzUaw/g/UY9rxNioMfIoydpjuxUFKK3/1Tvh4wibs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=POsAX31IWu/ZhM35wRUyOQm/LLL5C+CsYCR/eBwvf0NnHgI3lSsEkv8g9ME3OHu+g 5YLPzqT+WkhmOO8rKwKOdERg9WIadWU016pZySHkLwMkUZhyAgxHx5KPCcae34Vc+T OSfcqyfcZ1GEBpyZ81RULmKvq/ZcxNq7QHO+TFnSvZUML/6mUMAyT23+9zv6Kzei9v qM9lH81J0rCzK4N/EeBpMfRGOLtMOSzMlyk/CAzOv72ub0kj8eq38+9T8743cVy0be HWIXZvNI+wMHHulBFG4Yqv+wbdW8Jyl1VqYUdj5AyOEImaan/gQ2P6Y3WTUlEk1JlS DB5Zm1Ma5jTJA== Date: Fri, 10 Jul 2026 20:24:12 -0400 From: Eric Biggers To: Keith Busch Cc: Keith Busch , linux-block@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, axboe@kernel.dk, brauner@kernel.org, aalbersh@kernel.org, jack@suse.cz, tytso@mit.edu, jaegeuk@kernel.org, cem@kernel.org Subject: Re: [PATCHv2 0/5] direct-io file extended attributes Message-ID: <20260711002412.GG1911@quark> References: <20260710210646.3576365-1-kbusch@meta.com> <20260710215328.GE1911@quark> Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jul 10, 2026 at 04:58:12PM -0600, Keith Busch wrote: > On Fri, Jul 10, 2026 at 05:53:28PM -0400, Eric Biggers wrote: > > On Fri, Jul 10, 2026 at 02:06:41PM -0700, Keith Busch via Linux-f2fs-devel wrote: > > > From: Keith Busch > > > > > > The attributes reported through statx are incomplete for applications to > > > fully know exactly how IO construction is valid or not. The statx call > > > can report minimum memory alignment and total granularity, but it > > > doesn't show the underlying gap boundary requirements or max segments > > > per granule. > > > > > > This series adds the minimum to the extended file attributes through > > > file_getattr. I hear this is the preferred interface for reporting such > > > things over adding more fields to statx. In order to get everything > > > under a single syscall, some of the attributes are duplicated from > > > statx. > > > > Okay, in v2 we at least now know that the existing statx UAPI was > > considered. Could you give a specific real-world example (with the > > actual values of each parameter) where it's not sufficient? Without > > that there isn't really any way to evaluate this proposal. > > Yes, we can consider nvme. This protocol supports two different transfer > modes called PRP and SGL. PRP requires 4k aligned segments, though you > can have an arbitrary 4-byte aligned offset at the start. SGL on the > other hand allows completely arbitrary size and alignments for each > segment. > > statx reports information sufficient to know that you can have dword > aligned page offsets for a virtually contiguous buffer, but it doesn't > report PRP's boundary gap requirement, so applications can't tell if the > file follows PRP or SGL rules for direct-io. > > And if you have a device using SGL, statx doesn't report the max number > of sub-sector segments you can submit in a single command. > > This series provides both limits so user space has the complete picture. > > A typical nvme that supports only PRP has a DMA alignment of 4 bytes, a > dio offset alignment of 4k, and a virtual boundary of 4k. So each segment's length has to be a multiple of 4k, *and* it has to end on a 4k aligned memory address? That implies the segment begins at a 4k aligned memory address as well, which is just stx_dio_mem_align=4k. What am I missing? What is a specific example of an I/O request that you'd like to be able to submit that the existing UAPI can't declare support for? > If SGL were supported, there would be no virtual boundary gap, and max > segments is 256. Can you elaborate on why DIO users need to know max_segments? I'm worried about the UAPI duplication, as well as it going to be very difficult for userspace to correctly use this information. With just the two alignments there's at least a chance of them getting it right. If we throw virt_boundary_mask and max_segments into the mix, I don't think there's much chance. - Eric 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BC5D2C44501 for ; Sat, 11 Jul 2026 00:24:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YFe5Ux6byIZBaahmbO7YLco/dOSAA4wr9oh1IMe+Piw=; b=Q2NZGBsTvNwkYLWGsWxUzBbTax 0dpcl67GijwXXabKLPYbQXtDYHMkhi1wDPPZaea0ku4w2iUl5Q91E4rbRyvddSLAHLt0NcKJjoM5P PDeIEQ0eHHLXRcVoWYi2y6JZuWWz/HD0VjeiU7DNtxEO2rB+Xg/k2yw5qaBVKTTZ3ElA=; Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1wiLW6-0000KD-9f; Sat, 11 Jul 2026 00:24:27 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1wiLW5-0000K6-92 for linux-f2fs-devel@lists.sourceforge.net; Sat, 11 Jul 2026 00:24:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KFEzUaw/g/UY9rxNioMfIoydpjuxUFKK3/1Tvh4wibs=; b=ijpn056hI6i9ki1US0lh6Oo0MC c0H/PSL9utVOsepMZPQz1MfPw8ieODjUyTfXuB2GO3rnUAyhKtR+bdxrnokBtv+DoFfczcPHOLP/a wC7zEgP4e/DFopGk79/hIF5injGeD5qYTiP+QOmgu+w3Cd+5C0BOy/ZqJ8w9FuilCVWE=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KFEzUaw/g/UY9rxNioMfIoydpjuxUFKK3/1Tvh4wibs=; b=ZrNZbgKm75dJnhlp2UA0FSdVXW 74lf9XW+gOK5FCdYetT/Y5XlATjzaTajdN4HCxkDYioRyzPb2EKpFhxE75SoOy/4DhpjGQ5cX68pS GbCHqTKHHhITNZ7WJy96p6Ch17W3sCOtqqq9V1jsSKXDZAcmxh6HXeoBlUqvEckDQ7JY=; Received: from sea.source.kernel.org ([172.234.252.31]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1wiLW5-00053w-Hf for linux-f2fs-devel@lists.sourceforge.net; Sat, 11 Jul 2026 00:24:25 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 2C3AE43ADB; Sat, 11 Jul 2026 00:24:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC45D1F000E9; Sat, 11 Jul 2026 00:24:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783729454; bh=KFEzUaw/g/UY9rxNioMfIoydpjuxUFKK3/1Tvh4wibs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=POsAX31IWu/ZhM35wRUyOQm/LLL5C+CsYCR/eBwvf0NnHgI3lSsEkv8g9ME3OHu+g 5YLPzqT+WkhmOO8rKwKOdERg9WIadWU016pZySHkLwMkUZhyAgxHx5KPCcae34Vc+T OSfcqyfcZ1GEBpyZ81RULmKvq/ZcxNq7QHO+TFnSvZUML/6mUMAyT23+9zv6Kzei9v qM9lH81J0rCzK4N/EeBpMfRGOLtMOSzMlyk/CAzOv72ub0kj8eq38+9T8743cVy0be HWIXZvNI+wMHHulBFG4Yqv+wbdW8Jyl1VqYUdj5AyOEImaan/gQ2P6Y3WTUlEk1JlS DB5Zm1Ma5jTJA== Date: Fri, 10 Jul 2026 20:24:12 -0400 To: Keith Busch Message-ID: <20260711002412.GG1911@quark> References: <20260710210646.3576365-1-kbusch@meta.com> <20260710215328.GE1911@quark> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Headers-End: 1wiLW5-00053w-Hf Subject: Re: [f2fs-dev] [PATCHv2 0/5] direct-io file extended attributes X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eric Biggers via Linux-f2fs-devel Reply-To: Eric Biggers Cc: axboe@kernel.dk, linux-xfs@vger.kernel.org, brauner@kernel.org, aalbersh@kernel.org, Keith Busch , cem@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-block@vger.kernel.org, tytso@mit.edu, jaegeuk@kernel.org, linux-fsdevel@vger.kernel.org, jack@suse.cz, linux-ext4@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Fri, Jul 10, 2026 at 04:58:12PM -0600, Keith Busch wrote: > On Fri, Jul 10, 2026 at 05:53:28PM -0400, Eric Biggers wrote: > > On Fri, Jul 10, 2026 at 02:06:41PM -0700, Keith Busch via Linux-f2fs-devel wrote: > > > From: Keith Busch > > > > > > The attributes reported through statx are incomplete for applications to > > > fully know exactly how IO construction is valid or not. The statx call > > > can report minimum memory alignment and total granularity, but it > > > doesn't show the underlying gap boundary requirements or max segments > > > per granule. > > > > > > This series adds the minimum to the extended file attributes through > > > file_getattr. I hear this is the preferred interface for reporting such > > > things over adding more fields to statx. In order to get everything > > > under a single syscall, some of the attributes are duplicated from > > > statx. > > > > Okay, in v2 we at least now know that the existing statx UAPI was > > considered. Could you give a specific real-world example (with the > > actual values of each parameter) where it's not sufficient? Without > > that there isn't really any way to evaluate this proposal. > > Yes, we can consider nvme. This protocol supports two different transfer > modes called PRP and SGL. PRP requires 4k aligned segments, though you > can have an arbitrary 4-byte aligned offset at the start. SGL on the > other hand allows completely arbitrary size and alignments for each > segment. > > statx reports information sufficient to know that you can have dword > aligned page offsets for a virtually contiguous buffer, but it doesn't > report PRP's boundary gap requirement, so applications can't tell if the > file follows PRP or SGL rules for direct-io. > > And if you have a device using SGL, statx doesn't report the max number > of sub-sector segments you can submit in a single command. > > This series provides both limits so user space has the complete picture. > > A typical nvme that supports only PRP has a DMA alignment of 4 bytes, a > dio offset alignment of 4k, and a virtual boundary of 4k. So each segment's length has to be a multiple of 4k, *and* it has to end on a 4k aligned memory address? That implies the segment begins at a 4k aligned memory address as well, which is just stx_dio_mem_align=4k. What am I missing? What is a specific example of an I/O request that you'd like to be able to submit that the existing UAPI can't declare support for? > If SGL were supported, there would be no virtual boundary gap, and max > segments is 256. Can you elaborate on why DIO users need to know max_segments? I'm worried about the UAPI duplication, as well as it going to be very difficult for userspace to correctly use this information. With just the two alignments there's at least a chance of them getting it right. If we throw virt_boundary_mask and max_segments into the mix, I don't think there's much chance. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel