From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 1/1] gfs2: free disk inode which is deleted by remote node -V2
Date: Tue, 18 Aug 2009 10:16:37 +0100 [thread overview]
Message-ID: <1250586997.3403.1.camel@localhost.localdomain> (raw)
In-Reply-To: <200908180636.n7I6a1uf006460@rgminet15.oracle.com>
Hi,
That seems better. Now in the -nmw git tree. It might also be worth
returning 1 in the case that a NULL is found during the dereference
since there is no point caching a dentry with nothing attached to it. We
can fix that up later though. Thanks for the patch,
Steve.
On Tue, 2009-08-18 at 14:25 +0800, Wengang Wang wrote:
> this patch is for the same problem that Benjamin Marzinski fixes at commit
> b94a170e96dc416828af9d350ae2e34b70ae7347
>
> quotation of the original problem:
>
> ---cut here---
> When a file is deleted from a gfs2 filesystem on one node, a dcache
> entry for it may still exist on other nodes in the cluster. If this
> happens, gfs2 will be unable to free this file on disk. Because of this,
> it's possible to have a gfs2 filesystem with no files on it and no free
> space. With this patch, when a node receives a callback notifying it
> that the file is being deleted on another node, it schedules a new
> workqueue thread to remove the file's dcache entry.
> ---end cut---
>
> after applying Benjamin's patch, I think there is still a case in which the disk
> inode remains even when "no space" is hit. the case is that when running
> d_prune_aliases() against the inode, there are one or more dentries(aliases)
> which have reference count number > 0. in this case the dentries won't be pruned.
> and even later, the reference count becomes to 0, the dentries can still be
> cached in memory. unfortunately, no callback come again, things come back to
> the state before the callback runs. thus the on disk inode remains there until
> in memoryinode is removed for some other reason(shrinking inode cache or unmount
> the volume..).
>
> this patch is to remove those dentries when their reference count becomes to 0 and
> the inode is deleted by remote node. for implementation, gfs2_dentry_delete() is
> added as dentry_operations.d_delete. the function returns true when the inode is
> deleted by remote node. in dput(), gfs2_dentry_delete() is called and since it
> returns true, the dentry is unhashed from dcache and then removed. when all dentries
> are removed, the in memory inode get removed so that the on disk inode is freed.
>
> Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
> ---
> fs/gfs2/dentry.c | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/fs/gfs2/dentry.c b/fs/gfs2/dentry.c
> index 022c66c..91bedda 100644
> --- a/fs/gfs2/dentry.c
> +++ b/fs/gfs2/dentry.c
> @@ -107,8 +107,26 @@ static int gfs2_dhash(struct dentry *dentry, struct qstr *str)
> return 0;
> }
>
> +static int gfs2_dentry_delete(struct dentry *dentry)
> +{
> + struct gfs2_inode *ginode;
> +
> + if (!dentry->d_inode)
> + return 0;
> +
> + ginode = GFS2_I(dentry->d_inode);
> + if (!ginode->i_iopen_gh.gh_gl)
> + return 0;
> +
> + if (test_bit(GLF_DEMOTE, &ginode->i_iopen_gh.gh_gl->gl_flags))
> + return 1;
> +
> + return 0;
> +}
> +
> const struct dentry_operations gfs2_dops = {
> .d_revalidate = gfs2_drevalidate,
> .d_hash = gfs2_dhash,
> + .d_delete = gfs2_dentry_delete,
> };
>
prev parent reply other threads:[~2009-08-18 9:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-18 6:25 [Cluster-devel] [PATCH 1/1] gfs2: free disk inode which is deleted by remote node -V2 Wengang Wang
2009-08-18 9:16 ` Steven Whitehouse [this message]
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=1250586997.3403.1.camel@localhost.localdomain \
--to=swhiteho@redhat.com \
/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).