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)"
> > >
> > >
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)"
> > >
> > >
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)"
> > >
> > >
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 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 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 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 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 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 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: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: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
>
as_set(&xas, rac->_start + rac->_batch_count);
What on earth does this do? Comments please!
> +
> + if (batch == size)
> + break;
> + }
> +
> + return batch;
> +}
Seems a bit big for an inline function.
> +
> +
as_set(&xas, rac->_start + rac->_batch_count);
What on earth does this do? Comments please!
> +
> + if (batch == size)
> + 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
as_set(&xas, rac->_start + rac->_batch_count);
What on earth does this do? Comments please!
> +
> + if (batch == size)
> + 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
insertions(+), 126 deletions(-)
That's actually pretty simple changeover. Nothing really scary
there. :)
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
insertions(+), 126 deletions(-)
That's actually pretty simple changeover. Nothing really scary
there. :)
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
insertions(+), 126 deletions(-)
That's actually pretty simple changeover. Nothing really scary
there. :)
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
he."
Also: "This is almost 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
he."
Also: "This is almost 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
he."
Also: "This is almost 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
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
ead.c b/mm/readahead.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(&
ead.c b/mm/readahead.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(&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
ead.c b/mm/readahead.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(&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
&page->lru, &page_pool);
> + if (use_list) {
> + page->index = offset;
> + list_add(&page->lru, &page_pool);
> + } else if (add_to_page_cache_lru(page, mapping, offset,
> +
&page->lru, &page_pool);
> + if (use_list) {
> + page->index = offset;
> + list_add(&page->lru, &page_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
&page->lru, &page_pool);
> + if (use_list) {
> + page->index = offset;
> + list_add(&page->lru, &page_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
igned-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
___
Linux-f2fs-devel mailing list
igned-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
igned-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
ontrol.
>
> 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
ontrol.
>
> 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
ontrol.
>
> 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.
Ch
rac, &page_pool, gfp_mask);
> + rac._nr_pages = 0;
> }
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
rac, &page_pool, gfp_mask);
> + rac._nr_pages = 0;
> }
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
rac, &page_pool, gfp_mask);
> + rac._nr_pages = 0;
> }
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
efore continuing with the next
>* batch.
>*/
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages,
> - gfp_mask);
> -
efore continuing with the next
>* batch.
>*/
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages,
> - gfp_mask);
> -
efore continuing with the next
>* batch.
>*/
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages,
> - gfp_mask);
> -
el_init+0xe2/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
el_init+0xe2/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
el_init+0xe2/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...@fro
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
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
___
Linux-f2fs-devel mailing list
Linu
on'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
_
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
on'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
on'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
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
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
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
ge_nr_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
ge_nr_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 fun
ge_nr_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
>
gt;nid);
>
> - bio = NULL;
> - }
> + bio = NULL;
> + put_page(page);
> }
>
> - /* pages could still be locked */
> put_page(page);
A double put_page() on error?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
2, nr_pages = 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
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
2, nr_pages = 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
2, nr_pages = 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
contexts where the filesystem 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
statfs code should probably end up looking like this:
- if ((ip->i_d.di_flags & XFS_DIFLAG_PROJINHERIT) &&
+ if ((mp->m_flags & XFS_MOUNT_DIRQUOTA) &&
((mp->m_qflags & (XFS_PQUOTA_ACCT|XFS_PQUOTA_ENFD))) ==
(XFS_
and we don't have to worry about
subtly breaking random filesystems. Hence I'd suggest we sort out a
solution for DAX first, then worry about page cache stuff. The
shared page cache for reflink feature is not a show stopper -
multiple references for DAX is a show stopper. Let's
out that this isn't the way we want
to proceed with >y2038 on-disk support.
https://lore.kernel.org/linux-xfs/20191112161242.ga19...@infradead.org/T/#maf6b2719ed561cc2865cc5e7eb82df206b971261
I'd suggest taking the discussion there
Cheers,
Dave.
--
Dave Chinner
da...
On Tue, Nov 05, 2019 at 04:15:50PM +0100, David Sterba wrote:
> On Sat, Nov 02, 2019 at 08:38:23AM +1100, Dave Chinner wrote:
> > On Fri, Nov 01, 2019 at 09:57:31PM +0100, Geert Uytterhoeven wrote:
> > > Hi Valdis,
> > >
> > > On Thu, Oct 31, 2019 at 2
On Tue, Nov 05, 2019 at 04:15:50PM +0100, David Sterba wrote:
> On Sat, Nov 02, 2019 at 08:38:23AM +1100, Dave Chinner wrote:
> > On Fri, Nov 01, 2019 at 09:57:31PM +0100, Geert Uytterhoeven wrote:
> > > Hi Valdis,
> > >
> > > On Thu, Oct 31, 2019 at 2
On Tue, Nov 05, 2019 at 04:15:50PM +0100, David Sterba wrote:
> On Sat, Nov 02, 2019 at 08:38:23AM +1100, Dave Chinner wrote:
> > On Fri, Nov 01, 2019 at 09:57:31PM +0100, Geert Uytterhoeven wrote:
> > > Hi Valdis,
> > >
> > > On Thu, Oct 31, 2019 at 2
EDOTDOT 73 /* RFS specific error */
> #define EBADMSG 74 /* Not a data message */
> +#define EFSBADCRCEBADMSG /* Bad CRC detected */
Inconsistent whitespace here. When you get tab vs space after
#define wrong it only shows up in patches. :/
Chee
both errors should use different values?
That horse bolted to userspace years ago - this is just formalising
the practice that has spread across multiple linux filesystems from
XFS over the past ~10 years..
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
both errors should use different values?
That horse bolted to userspace years ago - this is just formalising
the practice that has spread across multiple linux filesystems from
XFS over the past ~10 years..
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
both errors should use different values?
That horse bolted to userspace years ago - this is just formalising
the practice that has spread across multiple linux filesystems from
XFS over the past ~10 years..
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
the block/fs drivers they already do
> > things normal daemons do not to meet that guarantee like mlock their
> > memory, disable oom killer, and preallocate resources they have control
> > over. They have no control over reclaim like the kernel drivers do so
> > its easy for us to deadlock when memory gets low.
>
> OK, fair enough. How much of a control do they really need though. Is a
> single PF_IO_FLUSHER as explained above (essentially imply GPF_NOIO
> context) sufficient?
I think some of these usrspace processes work at the filesystem
level and so really only need GFP_NOFS allocation (fuse), while
others work at the block device level (iscsi, nbd) so need GFP_NOIO
allocation. So there's definitely an argument for providing both...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
filesystems. Why not just hash the 64 bit inode, file
offset and block numbers into a single 64 bit value? It is still
unique enough for the stated use (i.e. unique IV for each file
block) but it doesn't limit what filesystem configurations can
actually
On Mon, Oct 21, 2019 at 03:49:31PM -0700, Ira Weiny wrote:
> On Mon, Oct 21, 2019 at 11:45:36AM +1100, Dave Chinner wrote:
> > On Sun, Oct 20, 2019 at 08:59:35AM -0700, ira.we...@intel.com wrote:
> > > @@ -1232,12 +1233,10 @@ xfs_diflags_to_linux(
> > >
in include/linux/capability.h...
Otherwise looks fine to me.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
gt; xfs_ilock(ip, XFS_MMAPLOCK_EXCL | XFS_IOLOCK_EXCL);
> +
> + if (i_size_read(inode) != 0) {
> + error = -EOPNOTSUPP;
> + goto out_unlock;
> + }
Wrong error. Should be the same as whatever is returned when we try
to change the extent size hint and can't because the file is
non-zero in length (-EINVAL, I think). Also needs a comment
explainging why this check exists, and probably better written as
i_size_read() > 0
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ption setting, giving applications a way of guranteeing they
aren't using DAX to access the data.
So if the mount option is going to live on, I suspect that we want
to keep this code as it stands.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
em. It is based on my previous series which
> added a Btrfs-specific ioctl [1], but it is now an extension to
> preadv2()/pwritev2() as suggested by Dave Chinner [2]. I've included a
> man page patch describing the API in detail. Test cases and examples
> programs are available [3].
&g
n
> ioend, and cancel a page that encountered an error before it was added to
> an ioend.
>
> Signed-off-by: Christoph Hellwig
With Darrick's renaming of the .submit_ioend method, this looks
fine.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
On Thu, Oct 17, 2019 at 11:39:17AM -0700, Darrick J. Wong wrote:
> On Thu, Oct 17, 2019 at 07:56:11PM +0200, Christoph Hellwig wrote:
> > From: Dave Chinner
> >
> > When doing a direct IO that spans the current EOF, and there are
> > written blocks beyond EOF that exte
mentation. 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
CH_MNT/file`
$ git grep 'stat -c "%s"'
tests/generic/286: test $(stat -c "%s" $src) = $(stat -c "%s" $dest) ||
tests/generic/286: test $(stat -c "%s" $src) = $(stat -c "%s" $dest) ||
tests/generic/286: test $(
On Tue, Oct 15, 2019 at 05:43:45PM +0200, Christoph Hellwig wrote:
> Move the initialization of ia and ib to the declaration line and remove
> a superflous else.
>
> Signed-off-by: Christoph Hellwig
nice little cleanup.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
> ---
> fs/iomap/buffered-io.c | 17 +
> include/linux/iomap.h | 17 -
> 2 files changed, 17 insertions(+), 17 deletions(-)
Sensible, nothing should be playing around with internal iomap
per-page state.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
INLINE))
> + continue;
> if (wpc->iomap.type == IOMAP_HOLE)
> continue;
> iomap_add_to_ioend(inode, file_offset, page, iop, wpc, wbc,
looks fine.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
+
> + trace_iomap_writepage(inode, page, 0, 0);
> +
> + /*
> + * Refuse to write the page out if we are called from reclaim context.
> + *
> + * This avoids stack overflows when called from deeply used stacks in
> + * random callers for direct reclaim or memcg reclaim. We explicitly
> + * allow reclaim from kswapd as the stack usage there is relatively low.
> + *
> + * This should never happen except in the case of a VM regression so
> + * warn about it.
> + */
> + if (WARN_ON_ONCE((current->flags & (PF_MEMALLOC|PF_KSWAPD)) ==
> + PF_MEMALLOC))
> + goto redirty;
> +
> + /*
> + * Given that we do not allow direct reclaim to call us, we should
> + * never be called while in a filesystem transaction.
> + */
never be called in a recursive filesystem reclaim context.
> + if (WARN_ON_ONCE(current->flags & PF_MEMALLOC_NOFS))
> + goto redirty;
> +
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Oct 15, 2019 at 05:43:41PM +0200, Christoph Hellwig wrote:
> Lift the xfs code for tracing address space operations to the iomap
> layer.
>
> Signed-off-by: Christoph Hellwig
OK.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
gt; also zero out mapped blocks with the new flag.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Darrick J. Wong
Sensible.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
On Tue, Oct 15, 2019 at 05:43:39PM +0200, Christoph Hellwig wrote:
> In preparation for moving the writeback code to iomap.c, replace the
> XFS-specific COW fork concept with the iomap IOMAP_F_SHARED flag.
>
> Signed-off-by: Christoph Hellwig
no problems I can spot.
Reviewed-by:
ig
looks good.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
s ok.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
ino
> Reviewed-by: Darrick J. Wong
Pretty straight forward.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
red for
> the iomap code to fully support file systems that don't do delayed
> allocations or use unwritten extents.
>
> Signed-off-by: Christoph Hellwig
looks fine.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
ck code. Replace the shared paramter with a set of initial
> flags an thus ensures the flags field is always reinitialized.
>
> Signed-off-by: Christoph Hellwig
Looks fine.
Reviewed-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
On Tue, Oct 01, 2019 at 02:01:57PM -0700, Ira Weiny wrote:
> On Mon, Sep 30, 2019 at 06:42:33PM +1000, Dave Chinner wrote:
> > On Wed, Sep 25, 2019 at 04:46:03PM -0700, Ira Weiny wrote:
> > > On Tue, Sep 24, 2019 at 08:26:20AM +1000, Dave Chinner wrote:
> > > > Hence
On Tue, Oct 01, 2019 at 02:01:57PM -0700, Ira Weiny wrote:
> On Mon, Sep 30, 2019 at 06:42:33PM +1000, Dave Chinner wrote:
> > On Wed, Sep 25, 2019 at 04:46:03PM -0700, Ira Weiny wrote:
> > > On Tue, Sep 24, 2019 at 08:26:20AM +1000, Dave Chinner wrote:
> > > > Hence
in it's buffer cache so it can find the cached page to link new
reflink copies to the same page...
ISTR a couple of other solutions were thrown around, but I don't
think anyone came up with a simple solution...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
in it's buffer cache so it can find the cached page to link new
reflink copies to the same page...
ISTR a couple of other solutions were thrown around, but I don't
think anyone came up with a simple solution...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
On Tue, Oct 08, 2019 at 08:34:36AM +0200, Christoph Hellwig wrote:
> On Tue, Oct 08, 2019 at 08:43:53AM +1100, Dave Chinner wrote:
> > > +static int
> > > +iomap_ioend_compare(void *priv, struct list_head *a, struct list_head *b)
> > > +{
> > > + struct i
oints, is largely a non-starter.
Also, inode_switch_wbs() is not guaranteed to move the inode to the
destination wb. There can only be WB_FRN_MAX_IN_FLIGHT (1024)
switches in flight at once and switches are run via RCU callbacks,
so I suspect that using inode_switch_wbs() for bulk re-assignment is
going to be a lot more complex than just finding inodes to call
inode_switch_wbs() on
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Fri, Oct 04, 2019 at 12:28:12PM -0700, Matthew Wilcox wrote:
> On Wed, Sep 25, 2019 at 06:36:50PM +1000, Dave Chinner wrote:
> > I'm actually working on abstrcting this code from both block size
> > and page size via the helpers below. We ahve need to support block
> >
701 - 800 of 3802 matches
Mail list logo
