[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20140702121245.b940538a410975ca91b40cfc@linux-foundation.org>
Date: Wed, 2 Jul 2014 12:12:45 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Jaegeuk Kim <jaegeuk@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH] f2fs: check bdi->dirty_exceeded when trying to skip
data writes
On Wed, 2 Jul 2014 02:31:26 -0700 Jaegeuk Kim <jaegeuk@...nel.org> wrote:
> > > --- a/fs/f2fs/node.c
> > > +++ b/fs/f2fs/node.c
> > > @@ -43,6 +43,8 @@ bool available_free_memory(struct f2fs_sb_info *sbi, int type)
> > > mem_size = (nm_i->nat_cnt * sizeof(struct nat_entry)) >> 12;
> > > res = mem_size < ((val.totalram * nm_i->ram_thresh / 100) >> 2);
> > > } else if (type == DIRTY_DENTS) {
> > > + if (sbi->sb->s_bdi->dirty_exceeded)
> > > + return false;
> > > mem_size = get_pages(sbi, F2FS_DIRTY_DENTS);
> > > res = mem_size < ((val.totalram * nm_i->ram_thresh / 100) >> 1);
> > > }
> >
> > err, filesystems should not be playing around with this.
> >
> > Perhaps VFS changes are needed. Please tell us much much more about
> > what is going on here.
>
> The f2fs has a feature which throttles IOs to merge bios in the fs level as much
> as possible by bypassing writepages in some cases.
OK, I just looked at fs/f2fs/data.c. AFAICT it has basically
bypassed/reimplemented/worked around the VFS.
That may be good or it may be bad. Maybe it indicates shortcomings in
the VFS, maybe it doesn't. Presumably there were good reasons for this
design but I am unable to determine what they were, because the code is
undocumented. No description of what it is trying to achieve or how or
why. It's just a great blob of C statements.
This is all rather a shame, because perhaps there were opportunities
here to improve the core VFS.
Oh well, I think I'll pretend I never saw it. Good luck!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists