Now that the xattr handler is passed to the xattr handler operations, we
have access to the attribute name prefix, so simplify
f2fs_xattr_generic_list.
Also, f2fs_xattr_advise_list is only ever called for
f2fs_xattr_advise_handler; there is no need to double check for that.
Signed-off-by: Andreas
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, September 22, 2015 2:40 AM
> To: Chao Yu
> Cc: linux-f2fs-devel@lists.sourceforge.net; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH 1/3] f2fs: introduce __try_update_largest_extent
>
>
This patch adds a new helper __try_update_largest_extent for cleanup.
Signed-off-by: Chao Yu
---
v2
o cleanup parameter passed.
fs/f2fs/extent_cache.c | 14 +-
fs/f2fs/f2fs.h | 7 +++
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/fs/f2fs/extent_cache.c
We pass 'nfree' to has_not_enough_free_secs to check whether there is
enough free section, but 'nfree' indicates the number of segment gced,
should alter the value to section number.
Signed-off-by: Chao Yu
---
fs/f2fs/gc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/
Hi Dan,
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Tuesday, September 22, 2015 12:25 AM
> To: chao2...@samsung.com
> Cc: linux-f2fs-devel@lists.sourceforge.net
> Subject: re: f2fs: reorganize f2fs_map_blocks
>
> Hello Chao Yu,
>
> The patch bce86
Third test, using the full device, on linux 4.2.1
mkfs.f2fs -l COLD1 -o1 -a0 -d1 -s128 /dev/mapper/xmnt-cold1
mount -tf2fs -onoatime,flush_merge,active_logs=2,no_heap
/dev/mapper/xmnt-cold1 /cold1
Unfortunately, mount failed with. The kernel showed that a high order
allocation could not be
Hi Chao,
On Tue, Sep 22, 2015 at 09:18:18PM +0800, Chao Yu wrote:
> We pass 'nfree' to has_not_enough_free_secs to check whether there is
> enough free section, but 'nfree' indicates the number of segment gced,
> should alter the value to section number.
Yeah, but I think we need to increase nfre
Thank you for the test.
On Tue, Sep 22, 2015 at 10:22:02PM +0200, Marc Lehmann wrote:
> Third test, using the full device, on linux 4.2.1
>
>mkfs.f2fs -l COLD1 -o1 -a0 -d1 -s128 /dev/mapper/xmnt-cold1
Could you check without -o1, since I merged a patch to calculate the best
overprovision at
On Mon, Sep 21, 2015 at 11:58:06AM +0200, Marc Lehmann wrote:
> Second test - we're getting there:
>
> Summary: looks much better, no obvious corruption (but fsck still gives
> tens of thousands of [FIX] messages), performance somewhat as expected,
> but a 138GB partition can only store 71.5GB of
In update_sit_info, we use div_u64 to handle 'u64 divide u64' case, but
div_u64 can only handle 32-bits divisor, so our divisor with u64 type
passed to div_u64 will overflow, result in the wrong calculation when
show debug info of f2fs as below:
BDF: 464, avg. vblocks: 23509
(BDF should never exce
On Tue, Sep 22, 2015 at 04:08:50PM -0700, Jaegeuk Kim
wrote:
> Could you check without -o1, since I merged a patch to calculate the best
> overprovision at runtime in f2fs-tools.
I assume I have it, as git pull didn't give me any updates.
> For example, if you set 1%, we need to reserve 100 sec
On Tue, Sep 22, 2015 at 06:12:39PM -0700, Jaegeuk Kim
wrote:
> Hmm. Is it necessary to reduce the number of active_logs?
I don't know, the documentation isn't very forthcoming with details :)
In any case, this is just for testing. My rationale was that multiple logs
probably means that there ar
On Wed, Sep 23, 2015 at 06:15:24AM +0200, Marc Lehmann
wrote:
> > However, when I tried to do mkfs.f2fs with the same options, I got about
> > 18GB.
> > Could you share the mkfs.f2fs messages and fsck.f2fs -d3 as well?
>
> When I re-ran the mkfs.f2fs, I got:
I get the feeling I did something i
> by metadata could br reduced, I'd risk f2fs in production in one system
> here.
Oh, and please, I beg you, consider increasing the hardlink limit to >16
bit - look at other filesystems,. many filesystems thought they could get
away with 16 bit (ext*, xfs, ...) but all of them nowadays support 31
14 matches
Mail list logo