On Tue, Jul 08, 2025 at 12:20:00PM +0200, Jan Kara wrote:
> On Mon 07-07-25 17:45:32, Darrick J. Wong wrote:
> > On Tue, Jul 08, 2025 at 08:52:47AM +0930, Qu Wenruo wrote:
> > > 在 2025/7/8 08:32, Dave Chinner 写道:
> > > > On Fri, Jul 04, 2025 at 10:
On Tue, Jul 08, 2025 at 08:52:47AM +0930, Qu Wenruo wrote:
>
>
> 在 2025/7/8 08:32, Dave Chinner 写道:
> > On Fri, Jul 04, 2025 at 10:12:29AM +0930, Qu Wenruo wrote:
> > > Currently all the filesystems implementing the
> > > super_opearations::shutdown() callback can not afford losing a device.
> >
On Tue, Jun 24, 2025 at 11:29:28AM +0530, Kundan Kumar wrote:
> On Wed, Jun 11, 2025 at 9:21 PM Darrick J. Wong wrote:
> >
> > On Wed, Jun 04, 2025 at 02:52:34PM +0530, Kundan Kumar wrote:
> > > > > > For xfs used this command:
> > > > > > xfs_
On Wed, Jun 25, 2025 at 09:14:51PM +0530, Kundan Kumar wrote:
> >
> > Makes sense. It would be good to test this on a non-SMP machine, if
> > you can find one ;)
> >
>
> Tested with kernel cmdline with maxcpus=1. The parallel writeback falls
> back to 1 thread behavior, showing nochange in BW.
>
ld be useful for xfs rt devices, if we could some day
reattach a resurrected bdev to a still-running filesystem
Looks good to me,
Acked-by: "Darrick J. Wong"
--D
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-e...@vger.kernel.org
> Cc: linux-f2fs-devel@lists.sourc
On Wed, Jun 04, 2025 at 02:52:34PM +0530, Kundan Kumar wrote:
> > > > For xfs used this command:
> > > > xfs_io -c "stat" /mnt/testfile
> > > > And for ext4 used this:
> > > > filefrag /mnt/testfile
> > >
> > > filefrag merges contiguous extents, and only counts up for discontiguous
> > > mappings,
hksum_driver:
> - *
> - * Reference to checksum algorithm driver via cryptoapi.
> - */
> - struct crypto_shash *j_chksum_driver;
> -
> /**
>* @j_csum_seed:
>*
>* Precomputed journal UUID checksum for seeding other checksums.
>*/
> @@ -1748,
-
> - return ext4_has_feature_metadata_csum(sb) &&
> -(EXT4_SB(sb)->s_chksum_driver != NULL);
> + return ext4_has_feature_metadata_csum(sb);
> }
Nit: Someone might want to
s/ext4_has_metadata_csum/ext4_has_feature_metadata_csum/ here to get rid
of the conf
On Thu, Jun 13, 2024 at 11:31:35AM +0100, John Garry wrote:
> On 12/06/2024 22:32, Darrick J. Wong wrote:
> > > unsigned int fs_block_size = i_blocksize(inode), pad;
> > > + u64 io_block_size = iomap->io_block_size;
> > I wonder, should iomap be nice and
On Thu, Jun 13, 2024 at 08:35:53AM +0100, John Garry wrote:
> On 12/06/2024 22:10, Darrick J. Wong wrote:
> > On Fri, Jun 07, 2024 at 02:38:58PM +, John Garry wrote:
> > > Add a generic helper for FSes to validate that an atomic write is
> > > appropriately sized (
On Fri, Jun 07, 2024 at 02:39:00PM +, John Garry wrote:
> Currently iomap->io_block_size is set to the i_blocksize() value for the
> inode.
>
> Expand the sub-fs block size zeroing to now cover RT extents, by calling
> setting iomap->io_block_size as xfs_inode_alloc_unitsize().
>
> In xfs_iom
On Fri, Jun 07, 2024 at 02:38:59PM +, John Garry wrote:
> Allow filesystems to set the io_block_size for sub-fs block size zeroing,
> as in future we will want to extend this feature to support zeroing of
> block sizes of larger than the inode block size.
>
> The value in io_block_size does no
On Fri, Jun 07, 2024 at 02:38:58PM +, John Garry wrote:
> Add a generic helper for FSes to validate that an atomic write is
> appropriately sized (along with the other checks).
>
> Signed-off-by: John Garry
> ---
> include/linux/fs.h | 12
> 1 file changed, 12 insertions(+)
>
>
mis.org/
>
> Cc: Masami Hiramatsu
> Cc: Mathieu Desnoyers
> Cc: Linus Torvalds
> Cc: Julia Lawall
> Signed-off-by: Steven Rostedt (Google)
/me finds this pretty magical, but such is the way of macros.
Thanks for being much smarter about them than me. :)
Acked-by: Darrick J. Won
On Wed, Apr 03, 2024 at 03:22:42AM -0400, Sweet Tea Dorminy wrote:
> Some filesystems support compressed extents which have a larger logical
> size than physical, and for those filesystems, it can be useful for
> userspace to know how much space those extents actually use. For
> instance, the comps
On Wed, Apr 03, 2024 at 02:17:26PM -0400, Kent Overstreet wrote:
> On Wed, Apr 03, 2024 at 03:22:41AM -0400, Sweet Tea Dorminy wrote:
> > For many years, various btrfs users have written programs to discover
> > the actual disk space used by files, using root-only interfaces.
> > However, this info
On Thu, Sep 28, 2023 at 01:06:03PM -0400, Jeff Layton wrote:
> On Thu, 2023-09-28 at 11:48 -0400, Arnd Bergmann wrote:
> > On Thu, Sep 28, 2023, at 07:05, Jeff Layton wrote:
> > > This shaves 8 bytes off struct inode, according to pahole.
> > >
> > > Signed-off-by: Jeff Layton
> >
> > FWIW, this
On Fri, Aug 25, 2023 at 09:54:02PM +0800, Hao Xu wrote:
> From: Hao Xu
>
> This series introduce getdents64 to io_uring, the code logic is similar
> with the snychronized version's. It first try nowait issue, and offload
> it to io-wq threads if the first try fails.
NAK on the entire series unti
gs & (S_CTIME|S_MTIME))
Minor nit: spaces around^ the operator.
Otherwise looks ok to me...
Acked-by: Darrick J. Wong
--D
> + now = inode_set_ctime_current(inode);
> + else
> + now = current_time(inode);
> +
> if (flags & S_MTIME)
> -
On Sat, Aug 05, 2023 at 10:32:39AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 02, 2023 at 09:32:19AM -0700, Darrick J. Wong wrote:
> > > + /* see get_tree_bdev why this is needed and safe */
> >
> > Which part of get_tree_bdev? Is it this?
> >
> >
i_delayed_blks);
>
> + fill_mg_cmtime(request_mask, inode, stat);
Huh. I would've thought @stat would come first since that's what we're
acting upon, but ... eh. :)
If everyone else is ok with the fill_mg_cmtime signature,
Acked-by: Darrick J. Wong
--D
> +
On Wed, Aug 02, 2023 at 05:41:31PM +0200, Christoph Hellwig wrote:
> Use the generic fs_holder_ops to shut down the file system when the
> log or RT device goes away instead of duplicating the logic.
>
> Signed-off-by: Christoph Hellwig
Nice cleanup,
Reviewed-by: Darrick J
On Wed, Aug 02, 2023 at 05:41:30PM +0200, Christoph Hellwig wrote:
> Just like get_tree_bdev needs to drop s_umount when opening the main
> device, we need to do the same for the xfs log and RT devices to avoid a
> potential lock order reversal with s_unmount for the mark_dead path.
>
> It might b
me; whose tree do you want this to go through?
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/libfs.c | 41
> include/linux/fs.h | 2 ++
> mm/filemap.c | 66 +++---
> 3 files changed, 58 insertions(+)
gt; Signed-off-by: Christoph Hellwig
Yay code removal!!!! :)
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/btrfs/file.c | 6 +-
> fs/ceph/file.c| 4
> fs/ext4/file.c| 2 --
> fs/f2fs/file.c| 2 --
> fs/fuse/file.c| 4
&g
t, for while we'll want to an use iomap based buffered
> write path in the block layer.
Heh.
For patches 3 and 8, I wonder if you could just get rid of
current->backing_dev_info?
For patches 2, 4-6, and 10:
Acked-by: Darrick J. Wong
For patches 1, 7, and 9:
Reviewed-by: Darrick J. Wong
On Fri, May 19, 2023 at 11:35:16AM +0200, Christoph Hellwig wrote:
> Move the assignment to current->backing_dev_info from the callers into
> iomap_file_buffered_write to reduce boiler plate code and reduce the
> scope to just around the page dirtying loop.
>
> Note that zonefs was missing this as
On Mon, Apr 24, 2023 at 07:49:20AM +0200, Christoph Hellwig wrote:
> Move the assignment to current->backing_dev_info from the callers into
> iomap_file_buffered_write. Note that zonefs was missing this assignment
> before.
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/gfs2/file.c | 3
On Wed, Apr 05, 2023 at 06:02:21PM +0200, Andrey Albershteyn wrote:
> Hi Darrick,
>
> On Tue, Apr 04, 2023 at 09:36:02AM -0700, Darrick J. Wong wrote:
> > On Tue, Apr 04, 2023 at 04:53:17PM +0200, Andrey Albershteyn wrote:
> > > In case of different Merkle tree bloc
On Wed, Apr 05, 2023 at 05:01:42PM +0200, Andrey Albershteyn wrote:
> On Tue, Apr 04, 2023 at 09:10:47AM -0700, Darrick J. Wong wrote:
> > On Tue, Apr 04, 2023 at 04:53:15PM +0200, Andrey Albershteyn wrote:
> > > The direct path is not supported on verity files. Attempts to us
On Wed, Apr 05, 2023 at 01:01:16PM +0200, Andrey Albershteyn wrote:
> Hi Christoph,
>
> On Tue, Apr 04, 2023 at 08:37:02AM -0700, Christoph Hellwig wrote:
> > > if (iomap_block_needs_zeroing(iter, pos)) {
> > > folio_zero_range(folio, poff, plen);
> > > + if (iomap->flags & IOM
On Wed, Apr 05, 2023 at 01:14:11AM +0800, Zorro Lang wrote:
> Darrick J. Wong would like to nominate Anand Jain to help more on
In case anyone's wondering how this all came about -- Anand asked me how
he could do more upstream fstests review work, so I suggested that he
and I talk to Zor
> F: tests/ocfs2/
>
> OVERLAYFS
> +R: Amir Goldstein
> L: linux-unio...@vger.kernel.org
> S: Supported
> F: tests/overlay
> @@ -174,6 +179,7 @@ S:Supported
> F: tests/udf/
>
> XFS
> +R: Darrick J. Wong
For this one hunk,
Reviewed-by:
On Tue, Apr 04, 2023 at 03:16:53PM -0700, Eric Biggers wrote:
> Hi Zorro,
>
> On Wed, Apr 05, 2023 at 01:14:09AM +0800, Zorro Lang wrote:
> > +FSVERITY
> > +L: fsver...@lists.linux.dev
> > +S: Supported
> > +F: common/verity
> > +
> > +FSCRYPT
> > +L: linux-fscr...@vger.kernel.org
> > +S: Sup
d
> +F: tests/udf/
> +
> +XFS
> +L: linux-...@vger.kernel.org
> +S: Supported
> +F: common/dump
> +F: common/fuzzy
> +F: common/inject
> +F: common/populate
note that populate and fuzzy apply to ext* as well.
> +F: common/repair
> +F: common/xf
On Wed, Apr 05, 2023 at 01:14:07AM +0800, Zorro Lang wrote:
> As fstests covers more and more fs testing, so we always get help
> from fs specific mailing list, due to they learn about their features
> and bugs more. Besides that, some folks help to review patches
> (relevant with them) more often.
On Tue, Apr 04, 2023 at 04:52:56PM +0200, Andrey Albershteyn wrote:
> Hi all,
>
> This is V2 of fs-verity support in XFS. In this series I did
> numerous changes from V1 which are described below.
>
> This patchset introduces fs-verity [5] support for XFS. This
> implementation utilizes extended
On Tue, Apr 04, 2023 at 04:53:17PM +0200, Andrey Albershteyn wrote:
> In case of different Merkle tree block size fs-verity expects
> ->read_merkle_tree_page() to return Merkle tree page filled with
> Merkle tree blocks. The XFS stores each merkle tree block under
> extended attribute. Those attrib
On Tue, Apr 04, 2023 at 04:53:16PM +0200, Andrey Albershteyn wrote:
> Add integration with fs-verity. The XFS store fs-verity metadata in
> the extended attributes. The metadata consist of verity descriptor
> and Merkle tree blocks.
>
> The descriptor is stored under "verity_descriptor" extended
>
On Tue, Apr 04, 2023 at 04:53:15PM +0200, Andrey Albershteyn wrote:
> The direct path is not supported on verity files. Attempts to use direct
> I/O path on such files should fall back to buffered I/O path.
>
> Signed-off-by: Andrey Albershteyn
> ---
> fs/xfs/xfs_file.c | 14 +++---
> 1
On Fri, Nov 04, 2022 at 11:32:35AM +1100, Dave Chinner wrote:
> On Thu, Nov 03, 2022 at 03:28:05PM -0700, Vishal Moola wrote:
> > On Wed, Oct 19, 2022 at 08:01:52AM +1100, Dave Chinner wrote:
> > > On Thu, Sep 01, 2022 at 03:01:19PM -0700, Vishal Moola (Oracle) wrote:
> > > > Converted function to
On Fri, Oct 14, 2022 at 08:48:35AM +, Hrutvik Kanabar wrote:
> From: Hrutvik Kanabar
>
> When `DISABLE_FS_CSUM_VERIFICATION` is enabled, return truthy value for
> `xfs_verify_cksum`, which is the key function implementing checksum
> verification for XFS.
>
> Signed-off-by: Hrutvik Kanabar
On Sat, Oct 08, 2022 at 03:56:22AM +0200, Alejandro Colomar wrote:
> Hi Eric,
>
> On 10/4/22 19:43, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Document the STATX_DIOALIGN support for statx()
> > (https://git.kernel.org/linus/725737e7c21d2d25).
>
On Tue, Oct 04, 2022 at 10:43:07AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Document the STATX_DIOALIGN support for statx()
> (https://git.kernel.org/linus/725737e7c21d2d25).
>
> Reviewed-by: Darrick J. Wong
> Signed-off-by: Eric Biggers
> ---
>
&g
On Thu, Oct 06, 2022 at 01:33:34AM -0700, Christoph Hellwig wrote:
> On Tue, Oct 04, 2022 at 10:13:51AM -0700, Daeho Jeong wrote:
> > From: Daeho Jeong
> >
> > introduce a new ioctl to replace the whole content of a file atomically,
> > which means it induces truncate and content update at the sa
er.kernel.org
> Cc: linux-f2fs-devel@lists.sourceforge.net
> Cc: linux-...@vger.kernel.org
> Cc: Christian Brauner
> Cc: Seth Forshee
Looks correct to me,
Reviewed-by: Darrick J. Wong
--D
> ---
> Documentation/filesystems/f2fs.rst |2 +-
> Docu
ticularly like the adjustment to report the
device's DMA alignment. Someone should probably fix DIONINFO, or
perhaps turn it into a getattr wrapper and hoist it? IMHO none of those
suggestions are necessary to land this patch, though.
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xf
On Fri, Jul 22, 2022 at 06:12:40PM +, Eric Biggers wrote:
> On Fri, Jul 22, 2022 at 10:53:42AM -0700, Darrick J. Wong wrote:
> > On Fri, Jul 22, 2022 at 12:36:01AM -0700, Eric Biggers wrote:
> > > [+f2fs list and maintainers]
> > >
> > > On Fri, Jun 10, 2
On Fri, Jul 22, 2022 at 12:36:01AM -0700, Eric Biggers wrote:
> [+f2fs list and maintainers]
>
> On Fri, Jun 10, 2022 at 12:58:30PM -0700, Keith Busch wrote:
> > From: Keith Busch
> >
> > Use the address alignment requirements from the block_device for direct
> > io instead of requiring addresse
ested information.
>
> This commit only adds the VFS-level plumbing for STATX_DIOALIGN. For
> regular files, individual filesystems will still need to add code to
> support it. For block devices, a separate commit will wire it up too.
>
> Reviewed-by: Christoph Hellwig
> Signed
The alignment (in bytes) required for file offsets and I/O segment lengths
> for
> +direct I/O
> +.BR "" ( O_DIRECT )
> +on this file, or 0 if direct I/O is not supported on this file.
On this last part -- userspace can only conclude that directio is not
supported on
On Fri, Jul 22, 2022 at 12:12:28AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add support for STATX_DIOALIGN to xfs, so that direct I/O alignment
> restrictions are exposed to userspace in a generic way.
>
> Signed-off-by: Eric Biggers
LGTM
Reviewed-by: Dar
On Thu, Jun 16, 2022 at 01:21:41PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Document the proposed STATX_DIOALIGN support for statx()
> (https://lore.kernel.org/linux-fsdevel/20220616201506.124209-1-ebigg...@kernel.org).
>
> Signed-off-by: Eric Biggers
> ---
> man2/open.2 | 43 +
On Thu, Jun 16, 2022 at 01:14:59PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Traditionally, the conditions for when DIO (direct I/O) is supported
> were fairly simple. For both block devices and regular files, DIO had
> to be aligned to the logical block size of the block device.
>
>
lesystems
> to use it.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Reviewed-by: Christoph Hellwig
LGTM
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/gfs2/aops.c | 2 +-
> fs/iomap/buffered-io.c | 25 -
> fs/xfs/xfs_aops.c | 2 +
On Fri, May 27, 2022 at 06:06:08PM -0700, Jaegeuk Kim wrote:
> On 05/27, Eric Biggers wrote:
> > [+Cc linux-block for FUA, and linux-xfs for iomap]
> >
> > On Fri, May 27, 2022 at 01:59:55PM -0700, Jaegeuk Kim wrote:
> > > Some UFS storage gives slower performance on FUA than write+cache_flush.
>
On Fri, May 27, 2022 at 11:02:46AM +0200, Florian Weimer wrote:
> * Eric Biggers:
>
> > diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
> > index 1500a0f58041a..f822b23e81091 100644
> > --- a/include/uapi/linux/stat.h
> > +++ b/include/uapi/linux/stat.h
> > @@ -124,9 +124,13 @@
On Wed, May 18, 2022 at 04:50:05PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Traditionally, the conditions for when DIO (direct I/O) is supported
> were fairly simple: filesystems either supported DIO aligned to the
> block device's logical block size, or didn't support DIO at all.
>
>
On Fri, Jan 21, 2022 at 10:57:55AM +1100, Dave Chinner wrote:
> On Thu, Jan 20, 2022 at 02:48:52PM -0800, Eric Biggers wrote:
> > On Fri, Jan 21, 2022 at 09:04:14AM +1100, Dave Chinner wrote:
> > > On Thu, Jan 20, 2022 at 01:00:27PM -0800, Darrick J. Wong wrote:
> > > &
On Thu, Jan 20, 2022 at 12:39:14PM -0800, Eric Biggers wrote:
> On Thu, Jan 20, 2022 at 09:10:27AM -0800, Darrick J. Wong wrote:
> > On Thu, Jan 20, 2022 at 12:30:23AM -0800, Christoph Hellwig wrote:
> > > On Wed, Jan 19, 2022 at 11:12:10PM -0800, Eric Biggers wrote:
> >
On Thu, Jan 20, 2022 at 12:30:23AM -0800, Christoph Hellwig wrote:
> On Wed, Jan 19, 2022 at 11:12:10PM -0800, Eric Biggers wrote:
> >
> > Given the above, as far as I know the only remaining objection to this
> > patchset would be that DIO constraints aren't sufficiently discoverable
> > by users
Hi Linus,
Please pull this single VFS patch that prevents userspace from setting
project quota ids on files that the VFS considers invalid.
This branch merges cleanly against your upstream branch as of a few
minutes ago, and does not introduce any fstests regressions for ext4 or
xfs.
--D
The fo
On Tue, Jul 27, 2021 at 04:30:16PM +0800, Chao Yu wrote:
> On 2021/7/27 15:38, Eric Biggers wrote:
> > That's somewhat helpful, but I've been doing some more investigation and
> > now I'm
> > even more confused. How can f2fs support non-overwrite DIO writes at all
> > (meaning DIO writes in LFS m
mitted by iomap will not have
> blocks with incontiguous DUNs by calling fscrypt_limit_io_blocks()
> appropriately.
>
> Signed-off-by: Eric Biggers
> Co-developed-by: Satya Tangirala
> Signed-off-by: Satya Tangirala
Looks like a straightforward conversion...
Acked-by: Darrick
On Fri, Jul 16, 2021 at 07:02:19AM +0100, Christoph Hellwig wrote:
> On Thu, Jul 15, 2021 at 03:40:10PM +0200, Jan Kara wrote:
> > Hello,
> >
> > here is another version of my patches to address races between hole punching
> > and page cache filling functions for ext4 and other filesystems. The on
e've never rejected -1 before. xfs_quota won't have
anything to do with that, and (assuming I read the helper/macro
gooeyness correctly) the vfs quota code won't either, so
Reviewed-by: Darrick J. Wong
--D
> }
>
> /* Check extent size hints. */
> --
>
o using it for reads makes
> the performance for mixed read-write workloads suffer.
>
> So create a new rw_semaphore in the address_space - invalidate_lock -
> that protects adding of pages to page cache for page faults / reads /
> readahead.
>
> Reviewed-by: D
On Mon, Jul 12, 2021 at 06:55:53PM +0200, Jan Kara wrote:
> Sync listing of struct file_operations members with the real one in
> fs.h.
>
> Acked-by: Darrick J. Wong
Might as well upgrade this to:
Reviewed-by: Darrick J. Wong
--D
> Reviewed-by: Christoph Hellwig
> Signe
On Thu, Jun 17, 2021 at 09:29:20AM -0700, Darrick J. Wong wrote:
> On Wed, Jun 16, 2021 at 05:57:12PM +0200, Jan Kara wrote:
> > On Wed 16-06-21 08:47:05, Darrick J. Wong wrote:
> > > On Wed, Jun 16, 2021 at 10:53:04AM +0200, Jan Kara wrote:
> > > > On Wed 16-06-
On Wed, Jun 16, 2021 at 05:57:12PM +0200, Jan Kara wrote:
> On Wed 16-06-21 08:47:05, Darrick J. Wong wrote:
> > On Wed, Jun 16, 2021 at 10:53:04AM +0200, Jan Kara wrote:
> > > On Wed 16-06-21 06:37:12, Christoph Hellwig wrote:
> > > > On Tue, Jun 15, 2021 at 11
iting code more recently than me...
Reviewed-by: Darrick J. Wong
--D
> Signed-off-by: Jan Kara
> ---
> fs/ext4/ext4.h | 10 --
> fs/ext4/extents.c | 25 +---
> fs/ext4/file.c | 13 +++--
> fs/ext4/inode.c| 47 +--
Signed-off-by: Pavel Reichl
> Suggested-by: Dave Chinner
> Suggested-by: Eric Sandeen
> Suggested-by: Darrick J. Wong
> Signed-off-by: Jan Kara
With the commit message updated,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_inode.c | 34 ++
o using it for reads makes
> the performance for mixed read-write workloads suffer.
>
> So create a new rw_semaphore in the address_space - invalidate_lock -
> that protects adding of pages to page cache for page faults / reads /
> readahead.
>
> Signed-off-by: Jan Kara
Looks
On Wed, Jun 16, 2021 at 10:53:04AM +0200, Jan Kara wrote:
> On Wed 16-06-21 06:37:12, Christoph Hellwig wrote:
> > On Tue, Jun 15, 2021 at 11:17:57AM +0200, Jan Kara wrote:
> > > From: Pavel Reichl
> > >
> > > Refactor xfs_isilocked() to use newly introduced __xfs_rwsem_islocked().
> > > __xfs_rw
On Mon, Jun 07, 2021 at 04:52:13PM +0200, Jan Kara wrote:
> Currently, serializing operations such as page fault, read, or readahead
> against hole punching is rather difficult. The basic race scheme is
> like:
>
> fallocate(FALLOC_FL_PUNCH_HOLE) read / fault / ..
> truncat
ointer based ordering VFS generally uses.
>
> CC: "Darrick J. Wong"
> Reviewed-by: Darrick J. Wong
> Signed-off-by: Jan Kara
Looks straightforward,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_bmap_util.c | 15 ---
> fs/xfs/xfs_inode.c | 37
alidate_lock.
>
> Reviewed-by: Christoph Hellwig
> CC:
> CC: "Darrick J. Wong"
> Signed-off-by: Jan Kara
> ---
> fs/xfs/xfs_file.c | 13 +++-
> fs/xfs/xfs_inode.c | 50 --
> fs/xfs/xfs_inode.h | 1 -
>
Signed-off-by: Pavel Reichl
> Suggested-by: Dave Chinner
> Suggested-by: Eric Sandeen
> Suggested-by: Darrick J. Wong
> Reviewed-by: Darrick J. Wong
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Jan Kara
> ---
> fs/xfs/xfs_inode.c | 39 +
ock ordering
rules...
Reviewed-by: Darrick J. Wong
--D
> ---
> include/linux/fs.h | 6 ++
> mm/filemap.c | 38 ++
> 2 files changed, 44 insertions(+)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index d8afbc96
On Mon, Jun 07, 2021 at 04:52:11PM +0200, Jan Kara wrote:
> inode->i_mutex has been replaced with inode->i_rwsem long ago. Fix
> comments still mentioning i_mutex.
>
> Reviewed-by: Christoph Hellwig
> Acked-by: Hugh Dickins
> Signed-off-by: Jan Kara
Looks good to me
On Wed, May 26, 2021 at 12:18:40PM +0200, Jan Kara wrote:
> On Tue 25-05-21 14:37:29, Darrick J. Wong wrote:
> > On Tue, May 25, 2021 at 03:50:44PM +0200, Jan Kara wrote:
> > > Use invalidate_lock instead of XFS internal i_mmap_lock. The intended
> > > purpose of inv
On Wed, May 26, 2021 at 03:45:18PM +0200, Jan Kara wrote:
> On Wed 26-05-21 12:11:43, Damien Le Moal wrote:
> > On 2021/05/26 19:07, Jan Kara wrote:
> > > On Tue 25-05-21 13:48:05, Darrick J. Wong wrote:
> > >> On Tue, May 25, 2021 at 03:50:41PM +0200, Jan Kara wrote
ointer based ordering VFS generally uses.
>
> Signed-off-by: Jan Kara
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_bmap_util.c | 15 ---
> fs/xfs/xfs_inode.c | 37 +++--
> 2 files changed, 19 insertions(+), 33 deletio
alidate_lock.
>
> Reviewed-by: Christoph Hellwig
> CC:
> CC: "Darrick J. Wong"
It's djw...@kernel.org now.
> Signed-off-by: Jan Kara
> ---
> fs/xfs/xfs_file.c | 12 ++-
> fs/xfs/xfs_inode.c | 52 ++
>
On Tue, May 25, 2021 at 03:50:40PM +0200, Jan Kara wrote:
> Currently, serializing operations such as page fault, read, or readahead
> against hole punching is rather difficult. The basic race scheme is
> like:
>
> fallocate(FALLOC_FL_PUNCH_HOLE) read / fault / ..
> truncat
inode1->mapping);
filemap_invalidate_lock_two(inode1->i_mapping, inode2->i_mapping);
To be fair, I've never been able to keep straight that down means lock
and up means unlock. Ah well, at least you didn't use "p" and "v".
Mechanically, the changes look ok to me
loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in,
> + struct file *file_out, loff_t pos_out,
> + loff_t len, unsigned int remap_flags);
Acked-by: Darrick J. Wong
The remap_file_range part looks correct to me. At a glance the others
seem fine too, b
On Fri, May 14, 2021 at 09:19:45AM +1000, Dave Chinner wrote:
> On Thu, May 13, 2021 at 11:52:52AM -0700, Darrick J. Wong wrote:
> > On Thu, May 13, 2021 at 07:44:59PM +0200, Jan Kara wrote:
> > > On Wed 12-05-21 08:23:45, Darrick J. Wong wrote:
> > > > On Wed, Ma
On Thu, May 13, 2021 at 07:44:59PM +0200, Jan Kara wrote:
> On Wed 12-05-21 08:23:45, Darrick J. Wong wrote:
> > On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote:
> > > +->fallocate implementation must be really careful to maintain page cache
> > > +cons
On Wed, May 12, 2021 at 03:46:11PM +0200, Jan Kara wrote:
> Currently, serializing operations such as page fault, read, or readahead
> against hole punching is rather difficult. The basic race scheme is
> like:
>
> fallocate(FALLOC_FL_PUNCH_HOLE) read / fault / ..
> truncat
ilock was removed by
> commit 467f78992a07 ("xfs: reduce ilock hold times in
> xfs_file_aio_write_checks").
>
> Remove this outdated comment.
>
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Eric Biggers
Yep, thanks for the update. :)
Reviewed-by: Darrick J. Won
On Tue, Nov 17, 2020 at 12:15:26PM -0500, Theodore Y. Ts'o wrote:
> What is the expected use case for Direct I/O using fscrypt? This
> isn't a problem which is unique to fscrypt, but one of the really
> unfortunate aspects of the DIO interface is the silent fallback to
> buffered I/O. We've lived
On Wed, Jul 22, 2020 at 04:26:25PM -0700, Eric Biggers wrote:
> On Wed, Jul 22, 2020 at 03:34:04PM -0700, Eric Biggers wrote:
> > So, something like this:
> >
> > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> > index 44bad4bb8831..2816194db46c 100644
> > --- a/fs/ext4/inode.c
> > +++ b/fs/ext4/
On Wed, Mar 25, 2020 at 11:21:13AM -0400, Theodore Y. Ts'o wrote:
> On Wed, Mar 25, 2020 at 02:20:57AM -0700, Christoph Hellwig wrote:
> > > spin_unlock(&inode->i_lock);
> > >
> > > - if (dirty & I_DIRTY_TIME)
> > > - mark_inode_dirty_sync(inode);
> > > + /* This was a lazytime expirati
On Wed, Feb 26, 2020 at 09:07:28AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 26, 2020 at 09:04:25AM -0800, Darrick J. Wong wrote:
> > > @@ -456,15 +435,8 @@ iomap_readpages(struct address_space *mapping,
> > > struct list_head *pages,
> > >
On Tue, Feb 25, 2020 at 01:48:38PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)"
>
> Use the new readahead operation in iomap. Convert XFS and ZoneFS to
> use it.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
> fs/iomap/buffered-io.c | 90 +++---
On Sun, Feb 23, 2020 at 08:33:55PM -0800, Matthew Wilcox wrote:
> On Fri, Feb 21, 2020 at 05:00:13PM -0800, Darrick J. Wong wrote:
> > On Thu, Feb 20, 2020 at 08:57:34AM -0800, Matthew Wilcox wrote:
> > > On Thu, Feb 20, 2020 at 07:49:12AM -0800, Chris
On Fri, Feb 21, 2020 at 05:54:35PM -0800, Matthew Wilcox wrote:
> On Fri, Feb 21, 2020 at 04:44:25PM -0800, Darrick J. Wong wrote:
> > On Wed, Feb 19, 2020 at 01:01:00PM -0800, Matthew Wilcox wrote:
> > > From: "Matthew Wilcox (Oracle)"
> > >
> > >
of the
mapping prior to submitting a read bio?
If so,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/buffered-io.c | 90 +++---
> fs/iomap/trace.h | 2 +-
> fs/xfs/xfs_aops.c | 13 +++---
> fs/zonefs/super.c | 7 ++--
>
On Thu, Feb 20, 2020 at 08:57:34AM -0800, Matthew Wilcox wrote:
> On Thu, Feb 20, 2020 at 07:49:12AM -0800, Christoph Hellwig wrote:
> > > +/**
> > > + * iomap_readahead - Attempt to read pages from a file.
> > > + * @rac: Describes the pages to be read.
> > > + * @ops: The operations vector for th
1 - 100 of 211 matches
Mail list logo
