On 21/06/2024 22:18, Darrick J. Wong wrote:
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 12/06/2024 22:47, Darrick J. Wong wrote:
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_s
e. As
such, if we then attempt this 16K atomic write, we get a single 16K BIO,
i.e. there is no unwritten extent conversion.
I am not sure if we should be doing this only for atomic writes inodes,
or also forcealign only or RT.
Thanks,
John
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
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 (along with the other checks).
Signed-off-by: John Garry
---
include/linux/fs.h | 12
1
On 07/06/2024 15:39, John Garry wrote:
For when forcealign is enabled, blocks in an inode need to be unmapped
according to extent alignment, like what is already done for rtvol.
Signed-off-by: John Garry
---
fs/xfs/libxfs/xfs_bmap.c | 33 -
1 file changed, 28
to be set for the file; for this,
FORCEALIGN and also ATOMICWRITES flags would also need to be set for the
inode.
Signed-off-by: John Garry
---
fs/xfs/xfs_file.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index
for the inode.
Signed-off-by: John Garry
---
fs/xfs/xfs_iops.c | 28
1 file changed, 28 insertions(+)
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index ff222827e550..d4c957793e07 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -563,6 +563,27
operation.
rtvol also guarantees extent alignment, but we are basing support initially
on forcealign, which is not supported for rtvol yet.
Signed-off-by: John Garry
---
fs/xfs/libxfs/xfs_format.h| 11 ++--
fs/xfs/libxfs/xfs_inode_buf.c | 52 +++
fs/xfs
d-off-by: John Garry
---
fs/xfs/xfs_file.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index eeb267ae2bf2..88ab743929fb 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -1172,6 +1172,18 @@ xfs_file_remap_range(
r
Support atomic writes by producing a single BIO with REQ_ATOMIC flag set.
We rely on the FS to guarantee extent alignment, such that an atomic write
should never straddle two or more extents. The FS should also check for
validity of an atomic write length/alignment.
Signed-off-by: John Garry
() time. This is the same story as FS_XFLAG_DAX, which signals to
the fs that we should try to enable the fsdax IO path on the file (instead
of the regular page cache), but applications have to query STAT_ATTR_DAX
to find out if they really got that IO path.
Signed-off-by: John Garry
---
include
For when forcealign is enabled, blocks in an inode need to be unmapped
according to extent alignment, like what is already done for rtvol.
Signed-off-by: John Garry
---
fs/xfs/libxfs/xfs_bmap.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git
From: "Darrick J. Wong"
Enable this feature.
Signed-off-by: "Darrick J. Wong"
Signed-off-by: John Garry
---
fs/xfs/libxfs/xfs_format.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.
igned-off-by: John Garry
---
fs/xfs/libxfs/xfs_bmap.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
index 2b6d5ebd8b4f..b3552cb5fc8f 100644
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -34
Like we already do for rtvol, only free full extents for forcealign in
xfs_free_file_space().
Signed-off-by: John Garry
---
fs/xfs/xfs_bmap_util.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 56b80a7c0992
force align configuration is present
yet, so this just triggers off an "always false" wrapper function
for the moment.
Signed-off-by: Dave Chinner
Signed-off-by: John Garry
---
fs/xfs/libxfs/xfs_alloc.h | 1 +
fs/xfs/libxfs/xfs_bmap.c | 29 +++--
fs/xfs/x
For forcealign enabled, the allocation unit size is in ip->i_extsize, and
this must never be zero.
Signed-off-by: John Garry
---
fs/xfs/xfs_inode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index a6cd5f1f2680..9c0ae5c3682e 100644
--- a/fs/
ignment, and always using args->prod/mod to indicate
extent length adjustment.
Signed-off-by: Dave Chinner
jpg: fixup alignslop references in xfs_trace.h and xfs_ialloc.c
Signed-off-by: John Garry
---
fs/xfs/libxfs/xfs_alloc.c | 4 +-
fs/xfs/libxfs/xfs_alloc.h | 2 +-
fs/xfs/libxfs/xf
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(+)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 069cbab62700
cation alignment
xfs: make EOF allocation simpler
xfs: introduce forced allocation alignment
xfs: align args->minlen for forced allocation alignment
John Garry (14):
fs: Add generic_atomic_write_valid_size()
iomap: Allow filesystems set IO block zeroing size
xfs: Use extent size granu
gnment constraint, fail the allocation immediately.
Signed-off-by: Dave Chinner
Signed-off-by: John Garry
---
fs/xfs/libxfs/xfs_bmap.c | 45 +++-
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
For when forcealign is enabled, we want the EOF to be aligned as well, so
do not free EOF blocks.
Signed-off-by: John Garry
---
fs/xfs/xfs_bmap_util.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index e5d893f93522
admins and users to mandate that all space
mappings in a file must have a startoff/blockcount that are aligned to
(say) a 2MB alignment and that the startblock/blockcount will follow the
same alignment.
Signed-off-by: "Darrick J. Wong"
Co-developed-by: John Garry
Signed-off-by: Joh
t reduce args->maxlen by some random,
arbitrary amount. If args->maxlen is too large for the available
space, reduce the allocation to a minlen allocation as we know we
have contiguous free space available for this to succeed and always
be correctly aligned.
Signed-off-by: Dave Chinner
Sig
.
Signed-off-by: John Garry
---
block/fops.c | 1 +
fs/btrfs/inode.c | 1 +
fs/erofs/data.c | 1 +
fs/erofs/zmap.c | 1 +
fs/ext2/inode.c | 1 +
fs/ext4/extents.c | 1 +
fs/ext4/inode.c | 1 +
fs/f2fs/data.c| 1 +
fs/fuse/dax.c | 1
making things a lot simpler when forced alignment is introduced.
Signed-off-by: Dave Chinner
Signed-off-by: John Garry
---
fs/xfs/libxfs/xfs_bmap.c | 129 +++--
fs/xfs/libxfs/xfs_ialloc.c | 2 +-
2 files changed, 54 insertions(+), 77 deletions(-)
diff --git
o an aligned size.
Signed-off-by: Dave Chinner
Signed-off-by: John Garry
---
fs/xfs/libxfs/xfs_alloc.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c
index 5855a21d4864..32f72217c126 100644
--- a/fs/xfs/libxf
extent granularity.
In xfs_file_dio_write(), handle a write which is not aligned to extent
size granularity as unaligned. Since the extent size granularity need not
be a power-of-2, handle this also.
Signed-off-by: John Garry
---
fs/xfs/xfs_file.c | 24 +++-
fs/xfs/xfs_i
mean "everything else), this upgrade really should
simply be done in place.
I don't see much in the following patches that *truly* requires forking
these files. And if you fix them up in place, then more people will be
able to find the fstests maintainers easily, too.
thanks,
--
Jo
+= $(cflags-y)
KBUILD_AFLAGS += $(cflags-y)
If you agree, can you post a patch to LKML so we can unbreak the SH build for
CONFIG_WERROR?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-
ed.
Could you post a kernel patch for that? I would be happy to test it on my
SH-7785CLR board. Also, I'm going to file a bug report against GCC.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF
ow to fix this then.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@li
NULL,
prio_registers, NULL);
Isn't this supposed to be caught by this check:
a, __same_type(a, NULL)
?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0
RRAY_SIZE(prio_regs), \
+ ARRAY_SIZE(sense_regs), ARRAY_SIZE(ack_regs), \
}
struct intc_desc {
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
^
./include/linux/sh_intc.h:105:31: note: in expansion of macro '_INTC_ARRAY'
105 | _INTC_ARRAY(vectors), _INTC_ARRAY(groups), \
| ^~~
Adrian
--
.''`. John Paul Adrian Glaubitz
Hi,
--- Original Message ---
On Friday, August 12th, 2022 at 2:13 PM, Jaegeuk Kim wrote:
>
> On 08/12, John Kehayias via Linux-f2fs-devel wrote:
>
> > Hello again,
> >
> > As this is the main disk for a homeserver, I was anxious to get it working
> >
ctual disk (memory card): resize.f2fs to shrink slightly (with -t ) and then resize it fully. Everything worked!
I have logs of the resizes and fscks happy to share though I know this has been
reported and seems fixed in current versions.
John
___
Linux-
system 4% cpu 4:24.44 total
I hope someone can help. It seems to just be a metadata issue? Is there a way
to manually fix the misreported block count to resolve this?
Thanks,
John
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
Sorry, should have prefaced the commit message with "f2fs-tools: ".
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
From: "John A. Leuenhagen"
---
README | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/README b/README
index 4ea3356..afe334f 100644
--- a/README
+++ b/README
@@ -1,8 +1,8 @@
-F2FS format utilility
+F2FS format utility
-
-T
default options, the `-g` option
could be used with a new `default-options` value, i.e. `-g example`.
Signed-off-by: John A. Leuenhagen
---
man/mkfs.f2fs.8 | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/man/mkfs.f2fs.8 b/man/mkfs.f2fs.8
index 0aca4dc..c90ebcc
On Wed, Dec 16, 2020 at 10:26:54PM -0800, Jaegeuk Kim wrote:
> Hi,
>
> On 12/14, John A. Leuenhagen via Linux-f2fs-devel wrote:
> > The man page states that simply specifying the -g option will use the
> > default Android options. However, mkfs.f2fs currently requires the us
The man page states that simply specifying the -g option will use the
default Android options. However, mkfs.f2fs currently requires the user
to specify `-g android`. This makes the behavior of mkfs.f2fs match the
man page.
Signed-off-by: John A. Leuenhagen
---
mkfs/f2fs_format_main.c | 5
Signed-off-by: John A. Leuenhagen
---
man/mkfs.f2fs.8 | 1 +
1 file changed, 1 insertion(+)
diff --git a/man/mkfs.f2fs.8 b/man/mkfs.f2fs.8
index 0aca4dc..8c57216 100644
--- a/man/mkfs.f2fs.8
+++ b/man/mkfs.f2fs.8
@@ -141,6 +141,7 @@ Add default Android options.
.TP
.BI \-i
Enable extended
ds like a clumsy
API design to *disable*, right?). And there is no hint about the scope.
And it *could* be so much more readable like this:
dev_access_enable(DEV_ACCESS_THIS_THREAD);
thanks,
--
John Hubbard
NVIDIA
___
Linux-f2fs-devel
These two arguments would simply print the usage message.
Signed-off-by: John A. Leuenhagen
---
man/mkfs.f2fs.8 | 3 +++
mkfs/f2fs_format_main.c | 12 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/man/mkfs.f2fs.8 b/man/mkfs.f2fs.8
index e2aee76..7745177
On Wed, Mar 25, 2020 at 3:59 PM Jaegeuk Kim wrote:
> > Is it normal to return 0 bytes trimmed for F2FS partitions? By
>
> It's normal, and that's why I asked -o nodiscard. The reason is F2FS creates
> asynchronous discard thread to alleviate long discarding latency among RW IOs.
> It keeps candid
On Wed, Mar 25, 2020 at 2:41 PM John wrote:
> I can confirm that it is true with an encrypted ext4 partition. I get
> the same error, "fstrim: /mnt/test: the discard operation is not
> supported" when I try it there on the same device. Unless there is a
> good reason for
On Wed, Mar 25, 2020 at 11:29 AM Jaegeuk Kim wrote:
> It seems dm-crypt has discard-related support, ie., "allow_discards", in ctrl.
> But, FWIW, the target simply doesn't support discard at all.
>
> # grep discards_supported drivers/md/*
> drivers/md/dm-cache-target.c: ti->discards_supported =
On Tue, Mar 24, 2020 at 9:01 PM Chao Yu wrote:
> I guess ssd should support discard, however I saw sdb was wrapped with device
> mapper, which may have different character, just want to check that whether
> device mapper disable the discard.
>
> If backup/restore is hard for you, how about let me
On Mon, Mar 23, 2020 at 11:02 AM Jaegeuk Kim wrote:
> > /dev/mapper/media-crypt /mnt/media f2fs
> > rw,lazytime,relatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix
>
On Mon, Mar 23, 2020 at 12:11 AM Jaegeuk Kim wrote:
>
> On 03/18, John wrote:
> > On Mon, Mar 16, 2020 at 9:44 PM Chao Yu wrote:
> > >
> > > On 2020/3/16 17:52, John wrote:
> > > > On Sun, Mar 15, 2020 at 9:24 PM Chao Yu wrote:
> > > >>
&
On Mon, Mar 16, 2020 at 9:44 PM Chao Yu wrote:
>
> On 2020/3/16 17:52, John wrote:
> > On Sun, Mar 15, 2020 at 9:24 PM Chao Yu wrote:
> >>
> >> What's your mount option and mkfs option on those two partitions, and
> >> what's
> >> your
On Sun, Mar 15, 2020 at 9:24 PM Chao Yu wrote:
>
> What's your mount option and mkfs option on those two partitions, and what's
> your kernel version?
I am mounting the partitions with systemd like so (/etc/fstab entry):
LABEL=incoming /incoming f2fs noauto,x-systemd.automount 0 0
Running `fstrim -a -v` is not detecting my f2fs partition that I
created just a few days ago but it does detect an older f2fs partition
and trims it as expected. Both partitions are on the same SSD. The
older partition is FSVER=1.12 whereas the newer one is FSVER=1.13
(reported by `lsblk -f`).
I
On 2/21/20 1:48 PM, Matthew Wilcox wrote:
> On Thu, Feb 20, 2020 at 06:43:31PM -0800, John Hubbard wrote:
>> Yes. But I think these files also need a similar change:
>>
>> fs/btrfs/disk-io.c
>
> That gets pagemap.h through ctree.h, so I think it&#x
On 2/21/20 7:35 AM, Matthew Wilcox wrote:
On Thu, Feb 20, 2020 at 07:50:39PM -0800, John Hubbard wrote:
This tiny patch made me pause, because I wasn't sure at first of the exact
intent of the lines above. Once I worked it out, it seemed like it might
be helpful (or overkill??) to add
6 +-
> Documentation/filesystems/vfs.rst | 15 +++
> include/linux/fs.h| 2 ++
> include/linux/pagemap.h | 18 ++
> mm/readahead.c| 12 ++--
> 5 files changed, 50 insertions(+), 3 deletions(
; 1 file changed, 7 insertions(+), 5 deletions(-)
>
Looks nice,
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 61b15b6b9e72..9fcd4e32b62d 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -119,
On 2/20/20 7:43 PM, Matthew Wilcox wrote:
> On Thu, Feb 20, 2020 at 07:19:58PM -0800, John Hubbard wrote:
>>> +static inline struct page *readahead_page(struct readahead_control *rac)
>>> +{
>>> + struct page *page;
>>> +
>>> + BUG_ON(rac->_ba
de's isize limit: */
if (index + nr_to_read >= end_index)
nr_to_read = end_index - index + 1;
Either way, it looks corrected written to me, so:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
>
> /*
>* Preallocate as
ead,
> unsigned long lookahead_size)
One more tiny thing: seeing as how this patch is also changing "size" to
"count",
maybe it should also change lookahead_size to lookahead_count.
thanks,
--
John Hubbard
NVIDIA
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
gfp_mask) < 0) {
I still think you'll want to compare against !=0, rather than < 0, here.
> + put_page(page);
> + read_pages(&rac, &page_pool);
Doing a read_pages() in the error case is because...actually, I'm not sure yet.
Wh
s as we will need.
>*/
> for (i = 0; i < nr_to_read; i++) {
> - pgoff_t page_offset = index + i;
ha, the naming mismatch I complained about in an earlier patch gets deleted
here, so we're good after all. :)
Looks good,
Reviewed-by: John Hubbar
t; + struct file *, pgoff_t index, unsigned long req_count);
Yes, "struct address_space *mapping" is weird, but I don't know if it's
"misleading", given that it's actually one of the things you have to learn
right from the beginning, with linux-mm, ri
code, to put your above note...and
there isn't one. But would it be terrible to just put a short comment
block at the top of this file, just so we have it somewhere? It's pretty
cool to settle on a consistent terminology, so backing it up with "yes, we
actually mean it" documenta
gt; And then kill readahead_for_each and open code the above to make it
>> even more obvious?
>
> Makes sense.
>
Great!
thanks,
--
John Hubbard
NVIDIA
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
On 2/18/20 5:02 PM, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 04:01:43PM -0800, John Hubbard wrote:
>> How about this instead? It uses the "for" loop fully and more naturally,
>> and is easier to read. And it does the same thing:
>>
>> static inli
if (!ctx.cur_page_in_bio)
> - unlock_page(ctx.cur_page);
> - put_page(ctx.cur_page);
> - }
> + BUG_ON(ctx.cur_page);
Is a full BUG_ON() definitely called for here? Seems like a WARN might
suffice...
>
> /*
>* Check that we didn't lose a page due to the arcance calling
>
thanks,
--
John Hubbard
NVIDIA
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
nx6/inode.c | 7 +++---
> fs/reiserfs/inode.c | 8 +++---
> fs/udf/inode.c | 7 +++---
> include/linux/mpage.h | 4 +--
> mm/migrate.c| 2 +-
> 18 files changed, 73 insertions(+), 126 del
On 2/18/20 6:23 PM, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 05:32:31PM -0800, John Hubbard wrote:
>>> + page_cache_readahead_limit(inode->i_mapping, NULL,
>>> + index, LONG_MAX, num_ra_pages, 0);
>>
>>
changed, 52 insertions(+), 83 deletions(-)
Just some minor ideas below, mostly documentation, so:
Reviewed-by: John Hubbard
>
> diff --git a/fs/ext4/verity.c b/fs/ext4/verity.c
> index dc5ec724d889..f6e0bf05933e 100644
> --- a/fs/ext4/verity.c
> +++ b/fs/ext4/verity.c
> @@ -
On 2/18/20 5:02 PM, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 04:01:43PM -0800, John Hubbard wrote:
>> How about this instead? It uses the "for" loop fully and more naturally,
>> and is easier to read. And it does the same thing:
>>
>> static inli
/linux/fs.h| 2 ++
> include/linux/pagemap.h | 18 ++
> mm/readahead.c| 8 +++-
> 5 files changed, 45 insertions(+), 2 deletions(-)
>
Looks nice,
Reviewed-by: John Hubbard
thanks,
--
John Hubbar
}
> if (i == nr_to_read - lookahead_size)
> SetPageReadahead(page);
> rac._nr_pages++;
> @@ -205,7 +205,7 @@ void __do_page_cache_readahead(struct address_space
> *mapping,
> continue;
> read:
>
On 2/17/20 10:45 AM, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)"
>
> Change the type of page_idx to unsigned long, and rename it -- it's
> just a loop counter, not a page index.
>
> Suggested-by: John Hubbard
> Signed-off-by: Matthew Wilcox (
x27;t see any other benefits
here: line count is about the same, for example).
What do you think? (I don't feel strongly about this fine point.)
thanks,
--
John Hubbard
NVIDIA
>
> - if (page_offset > end_index)
> + if (offset > end
On 2/18/20 2:57 PM, John Hubbard wrote:
> On 2/17/20 10:45 AM, Matthew Wilcox wrote:
>> From: "Matthew Wilcox (Oracle)"
>>
>> Eliminate the page_offset variable which was just confusing;
>> record the start of each consecutive run of pages in the
>
>
is not actually a bad thing, here. I'd rather
keep it, all other things being equal (and I don't see any other benefits
here: line count is the same, for example).
What do you think?
thanks,
--
John Hubbard
NVIDIA
> + struct page *page;
>
> - if (page
ask);
> @@ -201,6 +201,11 @@ void __do_page_cache_readahead(struct address_space
> *mapping,
> if (page_idx == nr_to_read - lookahead_size)
> SetPageReadahead(page);
> rac._nr_pages++;
> + continue;
> +read:
>
list_add(&page->lru, &page_pool);
> if (page_idx == nr_to_read - lookahead_size)
> SetPageReadahead(page);
> - nr_pages++;
> + rac._nr_pages++;
> }
>
> /*
> @@ -202,8 +208,8 @@ vo
On 2/18/20 1:21 PM, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 01:05:29PM -0800, John Hubbard wrote:
>> This is an easy review and obviously correct, so:
>>
>> Reviewed-by: John Hubbard
>
> Thanks
>
>> Thoughts for the future of the API:
>>
&
ig
> ---
> mm/readahead.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
Looks good,
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 8ce46d69e6ae..12d13b7792da 100644
> --- a/mm/rea
ns(+), 18 deletions(-)
This is an easy review and obviously correct, so:
Reviewed-by: John Hubbard
Thoughts for the future of the API:
I will add that I could envision another patchset that went in the
opposite direction, and attempted to preserve the information about
how many pages were succ
ere in this thread, "[LSF/MM/BPF TOPIC] FS Maintainers Don't Scale":
https://lore.kernel.org/r/20200131052520.GC6869@magnolia
thanks,
--
John Hubbard
NVIDIA
>
> v6:
> - Name the private members of readahead_control with a leading underscore
>(suggested by Chr
.h| 2 +
> include/linux/pagemap.h | 54 +++
> mm/readahead.c| 48 ++--
> 5 files changed, 102 insertions(+), 21 deletions(-)
>
A minor question below, but either way you can add:
Rev
On 2/13/20 8:21 PM, Matthew Wilcox wrote:
> On Thu, Feb 13, 2020 at 07:19:53PM -0800, John Hubbard wrote:
>> On 2/10/20 5:03 PM, Matthew Wilcox wrote:
>>> @@ -161,7 +161,7 @@ unsigned int __do_page_cache_readahead(struct
>>> address_space *mapping,
>>> un
read */
> LIST_HEAD(page_pool);
> int page_idx;
What about page_idx, too? It should also have the same data type as nr_pages,
as long as
we're trying to be consistent on this point.
Just want to ensure we're ready to handle those 2^33+ page readaheads... :)
thanks,
;* Preallocate as many pages as we will need.
>*/
> for (page_idx = 0; page_idx < nr_to_read; page_idx++) {
> - pgoff_t page_offset = offset + page_idx;
> + struct page *page;
I see two distinct things happening in this patch, and I thi
On Sun, Dec 08, 2019 at 04:38:04AM -0800, Matthew Wilcox wrote:
> On Sun, Dec 08, 2019 at 03:41:44AM +, Al Viro wrote:
> > On Sat, Dec 07, 2019 at 07:35:48PM +0800, Tiezhu Yang wrote:
> > > There exists many similar and duplicate codes to check "." and "..",
> > > so introduce is_dot_dotdot hel
Hi Matthew!
On 01/17/2018 09:20 PM, Matthew Wilcox wrote:
> Use the xarray infrstructure like we used the radix tree infrastructure.
> This lets us get rid of idr_get_free() from the radix tree code.
There's a typo: infrstructure => infratructure
Cheers,
Adrian
--
.'&#
have no objections to it being merged for 4.12.
If it isn't this change is already queued up for the apparmor 4.13
merge
Acked-by: John Johansen
> ---
> security/apparmor/apparmorfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/apparmor
mps here.
>>
>> Do you still see problems if you use current_kernel_time() instead of
>> ktime_get_real_ts()?
>
> The problem disappears after using current_kernel_time().
>
> https://github.com/ceph/ceph-client/commit/2e0f648da23167034a3cf1500bc90ec60aef2417
>Fro
On Sun, Dec 22, 2013 at 5:13 PM, Jaegeuk Kim wrote:
> Hi,
>
> I couldn't get any error when replaying your scenario on my arm board.
> So, could you send the backtrace of any hanged process?
>
> # cat /proc/[pid]/stack
>
> Thanks,
>
> 2013-12-20 (금), 12:29 -080
Nothing in the kernel log. Disabling discard when formatting the partition
doesn't help.
On Dec 21, 2013 1:06 PM, "Chris Fries" wrote:
> Anything show up in the kernel log from the block device? You might try
> turning off discard, see if that helps.
> On Dec 21,
Note: this is on a M8G2FA Samsung flash chip.
On Fri, Dec 20, 2013 at 12:29 PM, John Grub wrote:
> Hello,
>
> I can't seem to write larger files on my f2fs mount.
> My hardware is an embedded arm platform with an 8GB eMMC nand flash chip:
> Golbal
iling copy, I've seen 4k, 8k and 12k copied correctly before it
stops.
Test case #3: Copy a 150k file to f2fs:
# cp /tmp/150k /mnt/f2fs/
This never completes and will hang forever if I don't kill it. It always
see
97 matches
Mail list logo
