Re: [PATCH v6 0/7] fs/dcache: Track & limit # of negative dentries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 12, 2018 at 10:21 AM James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 2018-07-12 at 09:49 -0700, Matthew Wilcox wrote:
> >
> > I don't know that it does work.  Or that it works well.
>
> I'm not claiming the general heuristics are perfect (in fact I know we
> still have a lot of problems with dirty reclaim and writeback).

I think this whole "this is about running out of memory" approach is wrong.

We *should* handle that well. Or well enough in practice, at least.

Do we? Maybe not. Should the dcache be the one area to be policed and
worked around? Probably not.

But there may be other reasons to just limit negative dentries.

What does the attached program do to people? It's written to be
intentionally annoying to the dcache.

               Linus
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>

static void die(const char *msg)
{
	fputs(msg, stderr);
	exit(1);
}

/*
 * Use a "longish" filename to make more trouble for the dcache.
 *
 * The inline length is 32-40 bytes depending on kernel config,
 * so make it larger than that.
 */
int main(void)
{
	int i;
	char buffer[64];

	memset(buffer, 'a', sizeof(buffer));
	buffer[63] = 0;

	for (i = 0; i < 100000000; i++) {
		snprintf(buffer+40, sizeof(buffer)-40, "-%08d", i);
		if (open(buffer, O_RDONLY) >= 0)
			die("You're missing the point\n");
	}
	return 0;
}

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux