sure that all the Io is issued by unplugging the
device. The use of normal WRITEs for these buffers should
significantly reduce the overhead of processing in the cfq elevator
and enable the disk subsystem to get much closer to disk bandwidth
for large sequential writes.
Signed-off-by: Dave Chinner
These patches improve sequential write IO patterns and reduce ordered
write log contention.
The first patch is simply for diagnosis purposes - it enabled me to
see where Io was being dispatched from, and led directly to he fix
in the second patch. The third patch removes the use of
steps first, though. ;)
Cheers,
Dave.
--
Dave Chinner
dchin...@redhat.com
of the patch again and I
can't see anything obviously wrong with it, so queue it up ;)
Cheers,
Dave.
--
Dave Chinner
dchin...@redhat.com
On Fri, Dec 07, 2012 at 05:25:19PM +0530, Abhijit Pawar wrote:
This patch replace the obsolete simple_strtofoo with kstrtofoo
The XFS changes look fine. Consider those:
Acked-by: Dave Chinner dchin...@redhat.com
--
Dave Chinner
da...@fromorbit.com
the LRU operations the innermost operations for
locking purposes
d) convert to list_lru operations...
Cheers,
Dave.
--
Dave Chinner
dchin...@redhat.com
On Sun, Dec 01, 2013 at 03:59:17AM -0800, Christoph Hellwig wrote:
Also create inodes with the proper mode instead of fixing it up later.
Signed-off-by: Christoph Hellwig h...@lst.de
Nice cleanup work, Christoph.
Reviewed-by: Dave Chinner dchin...@redhat.com
--
Dave Chinner
da
to be independent of the physical filesystem time encoding
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Jul 28, 2014 at 03:21:20PM -0600, Andreas Dilger wrote:
On Jul 25, 2014, at 6:38 PM, Dave Chinner da...@fromorbit.com wrote:
On Fri, Jul 25, 2014 at 10:52:57AM -0700, Zach Brown wrote:
On Fri, Jul 25, 2014 at 01:37:19PM -0400, Abhijith Das wrote:
Hi all,
The topic
On Mon, Jul 28, 2014 at 08:22:22AM -0400, Abhijith Das wrote:
- Original Message -
From: Dave Chinner da...@fromorbit.com
To: Zach Brown z...@redhat.com
Cc: Abhijith Das a...@redhat.com, linux-ker...@vger.kernel.org,
linux-fsdevel linux-fsde...@vger.kernel.org,
cluster
() can be
applied.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
the
bulkstat call and the open-by-handle as the generation number in the
handle will no longer match that of the inode.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Thu, Jul 31, 2014 at 01:19:45PM +0200, Andreas Dilger wrote:
On Jul 31, 2014, at 6:49, Dave Chinner da...@fromorbit.com wrote:
On Mon, Jul 28, 2014 at 03:19:31PM -0600, Andreas Dilger wrote:
On Jul 28, 2014, at 6:52 AM, Abhijith Das a...@redhat.com wrote:
OnJuly 26, 2014 12:27:19 AM
On Fri, Aug 01, 2014 at 07:54:56AM +0200, Andreas Dilger wrote:
On Aug 1, 2014, at 1:53, Dave Chinner da...@fromorbit.com wrote:
On Thu, Jul 31, 2014 at 01:19:45PM +0200, Andreas Dilger wrote:
None of these issues are relevant in the API that I'm thinking about.
The syscall just passes
On Wed, Oct 01, 2014 at 09:31:25PM +0200, Jan Kara wrote:
We support user, group, and project quotas. Tell VFS about it.
CC: x...@oss.sgi.com
CC: Dave Chinner da...@fromorbit.com
Signed-off-by: Jan Kara j...@suse.cz
---
fs/xfs/xfs_super.c | 2 ++
1 file changed, 2 insertions(+)
diff
interface that for example XFS could use
as well.
Hi Christoph. Can you send a link to the thread regarding Dave's iomap?
proposal? I don't recall it offhand, so I don't know what it was or
why it was never implemented. I assume you mean Dave Chinner. Maybe it's
time to revisit the concept as a long
On Wed, Feb 04, 2015 at 09:49:50AM +, Steven Whitehouse wrote:
Hi,
On 04/02/15 07:13, Oleg Drokin wrote:
Hello!
On Feb 3, 2015, at 5:33 PM, Dave Chinner wrote:
I also wonder if vmalloc is still very slow? That was the case some
time ago when I noticed a problem in directory access
On Wed, Feb 04, 2015 at 02:13:29AM -0500, Oleg Drokin wrote:
Hello!
On Feb 3, 2015, at 5:33 PM, Dave Chinner wrote:
I also wonder if vmalloc is still very slow? That was the case some
time ago when I noticed a problem in directory access times in gfs2,
which made us change to use kmalloc
context because the MM devs won't pass
the vmalloc gfp context down the stack to the PTE allocations
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Feb 02, 2015 at 01:57:23AM -0500, Oleg Drokin wrote:
Hello!
On Feb 2, 2015, at 12:37 AM, Dave Chinner wrote:
On Sun, Feb 01, 2015 at 10:59:54PM -0500, gr...@linuxhacker.ru wrote:
From: Oleg Drokin gr...@linuxhacker.ru
leaf_dealloc uses vzalloc as a fallback to kzalloc
On Mon, Mar 02, 2015 at 05:38:29AM +0100, Mateusz Guzik wrote:
On Sun, Mar 01, 2015 at 08:31:26AM +1100, Dave Chinner wrote:
On Sat, Feb 28, 2015 at 05:25:57PM +0300, Alexey Dobriyan wrote:
Freezing and thawing are separate system calls, task which is supposed
to thaw filesystem
of the user API - it's not defined
in the man page which just says can be up to 16 bytes.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
-nr_reclaimed += nr_reclaimed;
/*
--
1.8.3.1
--
Dave Chinner
da...@fromorbit.com
making a sweeping
generalisation that the IO stack plugging infrastructure
needs fundamental change?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
er calls into vfs inode shrinker to free inodes from memory.
> 7. dlm blocks on a pending fence operation. Goto 1.
Therefore, the fence operation should be doing GFP_NOFS allocations
to prevent re-entry into the DLM via the filesystem via the shrinker
Cheers,
Dave.
--
Dave Chinner
dchin...@redhat.com
n of the inode but do
not destroy/free it - you simply queue it to an internal list and
then do the cleanup/freeing in your own time?
i.e. why do you need a special callout just to defer freeing to
another thread when we already have hooks than enable you to do
this?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
then
move the parts of inode *freeing* that cause problems to a different
context via the ->evict/destroy callouts and trigger that external
context processing on demand. That external context can just do bulk
"if it is on the list then free it" processing, because the reclaim
policy has already been executed to place that inode on the reclaim
list.
This is essentially what XFS does, but it also uses the
->nr_cached_objects/->free_cached_objects() callouts in the
superblock shrinker to provide the reclaim rate feedback mechanism
required to throttle incoming memory allocations.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
-off-by: Eryu Guan <guane...@gmail.com>
> ---
>
> I noticed this when running LTP on overlayfs, setxattr03 failed due to
> unexpected EACCES on immutable inode.
This should be in the commit message itself, rather than "EPERM
looks more reasonable".
Other than that, change se
s that we
don't actually care about in XFS at all. That way I can carry all
the XFS changes in the XFS tree and not have to worry about when
this stuff gets merged or conflicts with the rest of the work that
is being done to the mm/ code and whatever tree that eventually
lands in...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
is simply going
to restart the flood of false positive lockdep warnings we've
silenced over the years, so perhaps lockdep needs to be made smarter
as well...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Apr 27, 2016 at 10:03:11AM +0200, Michal Hocko wrote:
> On Wed 27-04-16 08:58:45, Dave Chinner wrote:
> > On Tue, Apr 26, 2016 at 01:56:12PM +0200, Michal Hocko wrote:
> > > From: Michal Hocko <mho...@suse.com>
> > >
> > > THIS PATCH IS FOR TE
ntel CPU with local memory will be seen as a single node and so
will have a single kswapd thread to do reclaim. There's a massive
imbalance between maximum reclaim rate and maximum allocation rate
in situations like this. If we want memory reclaim to run faster,
we to be able to do more work *now*, not defer it to a context with
limited execution resources.
i.e. IMO deferring more work to a single reclaim thread per node is
going to limit memory reclaim scalability and performance, not
improve it.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ake the changes to the generic
superblock shrinker code to enable finer grained reclaim and
optimise the XFS shrinkers to make use of it...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Sun, May 01, 2016 at 08:19:44AM +1000, NeilBrown wrote:
> On Sat, Apr 30 2016, Dave Chinner wrote:
> > Indeed, blocking the superblock shrinker in reclaim is a key part of
> > balancing inode cache pressure in XFS. If the shrinker starts
> > hitting dirty inodes, it bl
On Tue, Jun 28, 2016 at 10:13:32AM +0100, Steven Whitehouse wrote:
> Hi,
>
> On 28/06/16 03:08, Dave Chinner wrote:
> >On Fri, Jun 24, 2016 at 02:50:11PM -0500, Bob Peterson wrote:
> >>This patch adds a new prune_icache_sb function for the VFS slab
> >>shrinker
y to do if it is already known
what ranges of the file contain zeros...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Nov 02, 2016 at 09:37:00AM +, Steven Whitehouse wrote:
> Hi,
>
> On 31/10/16 20:07, Dave Chinner wrote:
> >On Sat, Oct 29, 2016 at 10:24:45AM +0100, Steven Whitehouse wrote:
> >>On 28/10/16 20:29, Bob Peterson wrote:
> >>>+ if (create)
> >>
On Mon, Dec 19, 2016 at 02:06:19PM -0800, Darrick J. Wong wrote:
> On Tue, Dec 20, 2016 at 08:24:13AM +1100, Dave Chinner wrote:
> > On Thu, Dec 15, 2016 at 03:07:08PM +0100, Michal Hocko wrote:
> > > From: Michal Hocko <mho...@suse.com>
> > >
> &g
es
which audits and changes all the unnecessary KM_NOFS allocations
in one go. I've never liked whack-a-mole style changes like this -
do it once, do it properly
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
les
as holes. Hence this will now always report unwritten extents as
data . This strikes me as a regression as we currently report them
as a hole:
$ xfs_io -f -c "truncate 1m" -c "falloc 0 1m" -c "seek -a -r 0" foo
Whence Result
HOLE0
$
I'm pretty sure that ext4 has the same behaviour when it comes to
dirty page cache pages over unwritten extents ..
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
l
bufferhead free iomap IO path
Let's see what Christoph thinks first, though
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
e_end ops to the struct iomap_ops and have
existing implementations set them up as iomap_write_begin()/
iomap_write_end(). Then gfs2 can do it's special little extra bit
and then call iomap_write_end() in the one call...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
is made stable, so must
be the directory modification done during file creation.
This has nothing to do with POSIX or what the "linux standard" is -
this is testing whether the implementation of strictly ordered
metadata journalling is correct or not. If gfs2 does not have
strictly ordered metadata journalling, then it probably shouldn't
run these tests
Cheers,
Dave.
--
Dave Chinner
dchin...@redhat.com
hole series (all the mm changes and all the
| required fs changes) sent out for review prior to the merge window?
We're not asking for a description of what you are doing - we are
asking why the normal processes for proposing and merging such a
change is not being followed, and how you plan to rect
p granularity, rather than a per-syscall granularity.
i.e. if we do write(2GB), we want more than one balancing call
during that syscall, so it woul dbe up to the filesystem to a) limit
the size of write mappings to something smaller (e.g. 1024 pages)
so that there are still frequent balancing calls for large writes.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
the same time some other operation is
changing the size of the file, and that means this code no longer
does what you are intending it to do because the inode->i_size is no
longer constant across these operations...
Hence I think adding code that depends on i_rwsem to be held to
function correctly is the wrong direction to be taking the iomap
infrastructure.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ts for the iomap
and XFS branches - IMO, there's no really need to have a complete
new tree for it...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
);
See xfs_flush_unmap_range(), which is run under XFS_MMAPLOCK_EXCL
to serialise against incoming page faults...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Fri, Sep 06, 2019 at 11:48:31PM +0200, Andreas Gruenbacher wrote:
> On Fri, Sep 6, 2019 at 11:28 PM Dave Chinner wrote:
> > On Fri, Sep 06, 2019 at 10:52:41PM +0200, Andreas Gruenbacher wrote:
> > > Hi,
> > >
> > > I've just fixed a mmap write v
al conversion - what needs to be done to iomap and gfs2
to support the journalled data path so there's a single data IO
path?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
tion. GFS2 is already partially ported to
use the iomap infrastructure, though more work is needed to provide
the iomap functionality DAX requires. OCFS2 would require a lot more
work on this front
Cheers,
Dave.
--
Dave Chinner
dchin...@redhat.com
r_pages(page);
> + rac->start += rac->batch_count;
There's no mention of large page support in the patch description
and I don't recall this sort of large page batching in previous
iterations.
This seems like new functionality to me, not directly related to
the initial ->readahead API change? What have I missed?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Feb 03, 2020 at 06:46:41PM +0100, Christoph Hellwig wrote:
> On Sat, Jan 18, 2020 at 08:28:38PM +1100, Dave Chinner wrote:
> > I think it's pretty gross, actually. It makes the same mistake made
> > with locking in the old direct IO code - it encodes specific lock
> >
s = 2, left = 1, this looks up the
page at index 2, which is the one we issued IO on, not the one we
"left behind" which is at index 3.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
the next
>* batch.
>*/
> - if (nr_pages)
> - read_pages(mapping, filp, _pool, nr_pages,
> - gfp_mask);
> - nr_pages = 0;
> + if (readahead_count())
> + read_pages(, _pool, gfp_mask);
> + rac._nr_pages = 0;
Hmmm. Wondering ig it make sense to move the gfp_mask to the readahead
control structure - if we have to pass the gfp_mask down all the
way along side the rac, then I think it makes sense to do that...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
; + break;
> + }
> +
> + return batch;
> +}
Seems a bit big for an inline function.
> +
> +#define readahead_for_each_batch(rac, array, size, nr)
> \
> + for (; (nr = readahead_page_batch(rac, array, size)); \
> + readahead_next(rac))
I had to go look at the caller to work out what "size" refered to
here.
This is complex enough that it needs proper API documentation.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
-off-by: Matthew Wilcox (Oracle)
> ---
> mm/readahead.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Looks fine.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
_list) {
> + page->index = offset;
> + list_add(>lru, _pool);
> + } else if (add_to_page_cache_lru(page, mapping, offset,
> + gfp_mask) < 0) {
> + put_page(page);
> + goto read;
> + }
Ok, so that's why you put read code at the end of the loop. To turn
the code into spaghetti :/
How much does this simplify down when we get rid of ->readpages and
can restructure the loop? This really seems like you're trying to
flatten two nested loops into one by the use of goto
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ahead.c
> index 9e430daae42f..975ff5e387be 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -121,7 +121,13 @@ static void read_pages(struct readahead_control *rac,
> struct list_head *pages)
>
> blk_start_plug();
>
> - if (aops->readpages) {
> + if (aops->readahead) {
> + aops->readahead(rac);
> + readahead_for_each(rac, page) {
> + unlock_page(page);
> + put_page(page);
> + }
This needs a comment to explain the unwinding that needs to be done
here. I'm not going to remember in a year's time that this is just
for the pages that weren't submitted by ->readahead
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
Reviewed-by: Christoph Hellwig
> ---
> mm/readahead.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
Simple enough.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
nd we don't need to worry that a present page in the readahead
> window causes us to return a smaller nr_pages than we ought to have.
>
> Signed-off-by: Matthew Wilcox (Oracle)
Looks good.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
Also, why? This adds a goto from branched code that continues, then
adds a continue so the unbranched code doesn't execute the code the
goto jumps to. In absence of any explanation, this isn't an
improvement and doesn't make any sense...
--
Dave Chinner
da...@fromorbit.com
st certainly not the function you want to call.
Use page_cache_async_readahead or page_cache_sync_readahead()
instead."
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
e2/0xfa
[2.479776] ret_from_fork+0x1f/0x30
[2.480737] ---[ end trace e77079de9b22dc6a ]---
I just dropped the ext4 conversion from my local tree so I can boot
the machine and test XFS. Might have some more info when that
crashes and burns...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
t;
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
> mm/readahead.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
Looks ok, but having the readahead dispatch out of line from the
case that triggers it makes it hard to follow.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ed, 73 insertions(+), 126 deletions(-)
That's actually pretty simple changeover. Nothing really scary
there. :)
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
On Tue, Feb 18, 2020 at 05:42:30AM -0800, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 03:56:33PM +1100, Dave Chinner wrote:
> > Latest version in your git tree:
> >
> > $ ▶ glo -n 5 willy/readahead
> > 4be497096c04 mm: Use memalloc_nofs_save in readahead path
>
On Tue, Feb 18, 2020 at 05:56:18AM -0800, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 04:03:00PM +1100, Dave Chinner wrote:
> > On Mon, Feb 17, 2020 at 10:45:44AM -0800, Matthew Wilcox wrote:
> > > +static void read_pages(struct readahead_control *rac, struct list_
On Tue, Feb 18, 2020 at 11:54:04AM -0800, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 05:31:10PM +1100, Dave Chinner wrote:
> > On Mon, Feb 17, 2020 at 10:45:56AM -0800, Matthew Wilcox wrote:
> > > From: "Matthew Wilcox (Oracle)"
> > >
> &g
On Tue, Feb 18, 2020 at 05:57:36AM -0800, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 04:08:24PM +1100, Dave Chinner wrote:
> > On Mon, Feb 17, 2020 at 10:45:45AM -0800, Matthew Wilcox wrote:
> > > From: "Matthew Wilcox (Oracle)"
> > >
> > > Mov
On Tue, Feb 18, 2020 at 08:10:04AM -0800, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 05:21:47PM +1100, Dave Chinner wrote:
> > On Mon, Feb 17, 2020 at 10:45:54AM -0800, Matthew Wilcox wrote:
> > > From: "Matthew Wilcox (Oracle)"
> > >
> > > Th
On Tue, Feb 18, 2020 at 01:12:28PM -0800, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 05:57:58PM +1100, Dave Chinner wrote:
> > On Mon, Feb 17, 2020 at 10:45:59AM -0800, Matthew Wilcox wrote:
> > > From: "Matthew Wilcox (Oracle)"
&g
On Tue, Feb 18, 2020 at 07:42:22AM -0800, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 05:14:59PM +1100, Dave Chinner wrote:
> > On Mon, Feb 17, 2020 at 10:45:52AM -0800, Matthew Wilcox wrote:
> > > From: "Matthew Wilcox (Oracle)"
> > >
> > >
file changed, 9 insertions(+), 20 deletions(-)
Looks fine.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
On Tue, Feb 18, 2020 at 07:48:32PM -0800, Matthew Wilcox wrote:
> On Wed, Feb 19, 2020 at 02:45:25PM +1100, Dave Chinner wrote:
> > On Wed, Feb 19, 2020 at 08:26:52AM +1100, Dave Chinner wrote:
> > > On Tue, Feb 18, 2020 at 05:42:30AM -0800, Matthew Wilcox wrote:
> > > &
ctx->cur_page = NULL;
> + }
> }
>
> return done;
> @@ -451,11 +454,7 @@ iomap_readpages(struct address_space *mapping, struct
> list_head *pages,
> done:
> if (ctx.bio)
> submit_bio(ctx.bio);
> - if (ctx.cur_page) {
> -
On Tue, Feb 18, 2020 at 10:04:15PM -0800, Matthew Wilcox wrote:
> On Wed, Feb 19, 2020 at 02:29:00PM +1100, Dave Chinner wrote:
> > On Mon, Feb 17, 2020 at 10:46:11AM -0800, Matthew Wilcox wrote:
> > > @@ -418,6 +412,15 @@ iomap_readpages_actor(struct inode *inode, loff_t
> &
id of the get_page() call in fuse_readpages_fill().
>
> Signed-off-by: Matthew Wilcox (Oracle)
Looks OK.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
if (!ctx->cur_page_in_bio)
unlock_page(ctx->cur_page);
put_page(ctx->cur_page);
ctx->cur_page = NULL;
readahead_next(ctx->rac);
}
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
---
> fs/erofs/zdata.c | 2 +-
> include/trace/events/erofs.h | 6 +++---
> 3 files changed, 18 insertions(+), 29 deletions(-)
Looks fine from the perspective of page iteration and error handling.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
ext4.
I'll re-introduce the patch and see if it falls over again.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Feb 19, 2020 at 08:26:52AM +1100, Dave Chinner wrote:
> On Tue, Feb 18, 2020 at 05:42:30AM -0800, Matthew Wilcox wrote:
> > On Tue, Feb 18, 2020 at 03:56:33PM +1100, Dave Chinner wrote:
> > > Latest version in your git tree:
> > >
> > > $ ▶ glo -n 5 w
On Tue, Feb 11, 2020 at 04:54:13AM -0800, Matthew Wilcox wrote:
> On Tue, Feb 11, 2020 at 03:52:30PM +1100, Dave Chinner wrote:
> > > +struct readahead_control {
> > > + struct file *file;
> > > + struct address_space *mapping;
> > > +/* private
ystem wants/needs unlock on IO competion
semantics, and it's completely filesystem IO-lock implementation
agnostic. And for filesystems that use the inode i_rwsem, we can
just provide simple helper functions for their read/write unlock
methods.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ed by unpredicably
switching between direct IO and buffered IO (e.g. suddening DIO
writes serialise -all IO-) will cause unacceptible performance
regressions for many applications and be -very difficult to
diagnose- in production systems.
IOWs, we need to let the individual filesystems decide how they want
to use the page cache for direct IO. Just because we have new direct
IO infrastructure (i.e. iomap) it does not mean we can just make
wholesale changes to the direct IO path behaviour...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
cratering. Hopefully this will only be a rare event.
So, to hoist myself on my own petard: correctness first, performance
second.
Acked-by: Dave Chinner
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Thu, Jul 09, 2020 at 10:10:38AM -0700, Darrick J. Wong wrote:
> On Thu, Jul 09, 2020 at 06:05:19PM +0100, Matthew Wilcox wrote:
> > On Thu, Jul 09, 2020 at 09:09:26AM -0700, Darrick J. Wong wrote:
> > > On Thu, Jul 09, 2020 at 12:25:27PM +1000,
On Wed, Jul 08, 2020 at 02:54:37PM +0100, Matthew Wilcox wrote:
> On Wed, Jul 08, 2020 at 04:51:27PM +1000, Dave Chinner wrote:
> > On Tue, Jul 07, 2020 at 03:00:30PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 07, 2020 at 01:57:05PM +0100, Matthew Wilcox wrote:
> > &
ewed-by: Darrick J. Wong
> Signed-off-by: Darrick J. Wong
> ---
> fs/iomap/fiemap.c | 31 +--
> 1 file changed, 13 insertions(+), 18 deletions(-)
Looks good.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
/fs/iomap/apply.c b/fs/iomap/iter.c
> similarity index 100%
> rename from fs/iomap/apply.c
> rename to fs/iomap/iter.c
LGTM,
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
ng
> Signed-off-by: Darrick J. Wong
Looks like a straight translation of Christoph's original. Seems
fine to me as a simepl step towards preserving the git history.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
J. Wong
> Signed-off-by: Darrick J. Wong
> ---
> fs/iomap/apply.c | 91
> -
> fs/iomap/trace.h | 40 --
> include/linux/iomap.h | 10 -
> 3 files changed, 141 deletions(-)
Looks good.
Re
the older pre-disaggregation
fs/iomap.c without having to take the tree back in time to find
those files...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
_iterate() is fine as the function name - there's
no need for abbreviation here because it's not an overly long name.
This will makes it clearly different to the struct iomap_iter that
is passed to it and it will also make grep, cscope and other
code searching tools much more precise...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
y changing when both are used in the same function.
Would it be better to avoid any possible confusion simply by using
"iomi" for all iomap_iter variables throughout the patchset from the
start? That way nobody is going to confuse iov_iter with iomap_iter
iteration variables and code that
operly first informing the file system in a context where it can
> block and potentially do I/O to do things like allocate blocks.
I'm not sure that replacing the BUG() with a warning is good enough
- it's still indicative of an application doing something dangerous
that could result in silent data corruption and/or other problems.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Feb 23, 2022 at 10:50:09PM -0500, Theodore Ts'o wrote:
> On Thu, Feb 24, 2022 at 12:48:42PM +1100, Dave Chinner wrote:
> > > Fair enough; on the other hand, we could also view this as making ext4
> > > more robust against buggy code in other subsystems, and while oth
ed the EOF boundary. Do this even
> if the read has IOCB_NOWAIT set, as it's the only way to avoid providing
> an unexpected result to an application.
That's highly specific and ultimately will be fragile, IMO. I'd much
prefer that *_iomap_begin_write() implementations simply follow
IOMAP_NOWAIT requirements to ensure that any DIO that needs multiple
mappings if punted to a context that can block...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Mar 02, 2022 at 02:03:28PM +0100, Andreas Gruenbacher wrote:
> On Wed, Mar 2, 2022 at 11:17 AM Filipe Manana wrote:
> > On Tue, Mar 01, 2022 at 09:38:30AM +1100, Dave Chinner wrote:
> > > On Mon, Feb 28, 2022 at 02:32:03PM +, fdman...@kernel.org wrote:
> >
On Sun, Aug 27, 2023 at 09:28:26PM +0800, Hao Xu wrote:
> From: Hao Xu
>
> Implement NOWAIT semantics for readdir. Return EAGAIN error to the
> caller if it would block, like failing to get locks, or going to
> do IO.
>
> Co-developed-by: Dave Chinner
Not really.
"C
1 - 100 of 141 matches
Mail list logo
