From: Waiman Long <longman@redhat.com>
To: "Wangkai (Kevin,C)" <wangkai86@huawei.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jonathan Corbet <corbet@lwn.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
Miklos Szeredi <mszeredi@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Larry Woodman <lwoodman@redhat.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries
Date: Thu, 17 Aug 2017 09:04:01 -0400 [thread overview]
Message-ID: <dd757d47-c8dd-81d5-0e94-8814aa680756@redhat.com> (raw)
In-Reply-To: <87B246BB5ED53A4C98E4F9A35839EDE185397B0E@nkgeml514-mbx.china.huawei.com>
On 08/17/2017 12:00 AM, Wangkai (Kevin,C) wrote:
>
>>>
>>> Hi Longman,
>>> I am a fresher of fsdevel, about 2 weeks before, I have joined this
>>> mail list, recently I have met the same problem of negative dentries,
>>> in my opinion, the dentries should be remove together with the files or
>> directories, I don't know you have submit this patch, I have another patch
>> about this:
>>> http://marc.info/?l=linux-fsdevel&m=150209902215266&w=2
>>>
>>> maybe this is a foo idea...
>>>
>>> regards
>>> Kevin
>> If you look at the code, the front dentries of the LRU list are removed when
>> there are too many negative dentries. That includes positive dentries as well as
>> it is not practical to just remove the negative dentries.
>>
>> I have looked at your patch. The dentry of a removed file becomes a negative
>> dentry. The kernel can keep track of those negative entries and there is no need
>> to add an additional flag for that.
>>
>> Cheers,
>> Longman
> One comment about your patch:
> In the patch 1/5 function dentry_kill first get dentry->d_flags, after lock parent and
> Compare d_flags again, is this needed? The d_flags was changed under lock.
Yes, it is necessary. We are talking about an SMP system with multiple
threads running concurrently. If you look at the lock parent code, it
may release the current dentry lock before taking the parent's and then
the dentry lock again. As soon as the lock is released, anything can
happen to the dentry including changes in d_flags.
> In my patch the DCACHE_FILE_REMOVED flag was to distinguish the removed file and
> The closed file, I found there was no difference of a dentry between the removed file and the closed
> File, they all on the lru list.
There is a difference between removed file and closed file. The type
field of d_flags will be empty for a removed file which indicate a
negative dentry. Anything else is a positive dentry. Look at the inline
function d_is_negative() [d_is_miss()] and you will see how it is done.
Cheers,
Longman
next prev parent reply other threads:[~2017-08-17 13:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 18:34 [PATCH v3 0/5] fs/dcache: Limit # of negative dentries Waiman Long
2017-07-28 18:34 ` [PATCH v3 1/5] fs/dcache: Limit numbers " Waiman Long
2017-07-28 18:34 ` [PATCH v3 2/5] fs/dcache: Report negative dentry number in dentry-state Waiman Long
2017-07-28 18:34 ` [PATCH v3 3/5] fs/dcache: Enable automatic pruning of negative dentries Waiman Long
2017-07-28 18:34 ` [PATCH v3 4/5] fs/dcache: Protect negative dentry pruning from racing with umount Waiman Long
2017-07-28 18:34 ` [PATCH v3 5/5] fs/dcache: Track count of negative dentries forcibly killed Waiman Long
2017-08-15 17:15 ` [PATCH v3 0/5] fs/dcache: Limit # of negative dentries Waiman Long
2017-08-16 10:33 ` Wangkai (Kevin,C)
2017-08-16 13:29 ` Waiman Long
2017-08-17 4:00 ` Wangkai (Kevin,C)
2017-08-17 13:04 ` Waiman Long [this message]
2017-08-18 9:59 ` Wangkai (Kevin,C)
2017-08-18 14:10 ` Waiman Long
2017-08-21 3:23 ` Wangkai (Kevin,C)
2017-08-21 13:34 ` Waiman Long
2017-08-22 2:59 ` Wangkai (Kevin,C)
2017-08-28 17:58 ` Waiman Long
2017-08-28 18:59 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dd757d47-c8dd-81d5-0e94-8814aa680756@redhat.com \
--to=longman@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lwoodman@redhat.com \
--cc=mingo@kernel.org \
--cc=mszeredi@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wangkai86@huawei.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).