From: Gang He <ghe@suse.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [patch 23/28] ocfs2: check/fix inode block for online file check
Date: Mon, 31 Aug 2015 21:35:27 -0600 [thread overview]
Message-ID: <55E58D7F020000F900013CB4@relay2.provo.novell.com> (raw)
In-Reply-To: <20150831205626.GB1145@wotan.suse.de>
Hello Mark,
Thanks for your reviewing, please see my comments inline.
>>>
> On Wed, Aug 26, 2015 at 03:12:22PM -0700, Andrew Morton wrote:
>> From: Gang He <ghe@suse.com>
>> Subject: ocfs2: check/fix inode block for online file check
>>
>> Implement online check or fix inode block during reading a inode block to
>> memory.
>>
>> Signed-off-by: Gang He <ghe@suse.com>
>> Reviewed-by: Goldwyn Rodrigues <rgoldwyn@suse.de>
>> Cc: Mark Fasheh <mfasheh@suse.com>
>> Cc: Joel Becker <jlbec@evilplan.org>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> ---
>>
>> fs/ocfs2/inode.c | 196 +++++++++++++++++++++++++++++++++++++--
>> fs/ocfs2/ocfs2_trace.h | 2
>> 2 files changed, 192 insertions(+), 6 deletions(-)
>>
>> diff -puN fs/ocfs2/inode.c~ocfs2-check-fix-inode-block-for-online-file-check
> fs/ocfs2/inode.c
>> --- a/fs/ocfs2/inode.c~ocfs2-check-fix-inode-block-for-online-file-check
>> +++ a/fs/ocfs2/inode.c
>> @@ -53,6 +53,7 @@
>> #include "xattr.h"
>> #include "refcounttree.h"
>> #include "ocfs2_trace.h"
>> +#include "filecheck.h"
>>
>> #include "buffer_head_io.h"
>>
>> @@ -74,6 +75,13 @@ static int ocfs2_truncate_for_delete(str
>> struct inode *inode,
>> struct buffer_head *fe_bh);
>>
>> +static int ocfs2_filecheck_read_inode_block_full(struct inode *inode,
>> + struct buffer_head **bh, int flags, int type);
>> +static int ocfs2_filecheck_validate_inode_block(struct super_block *sb,
>> + struct buffer_head *bh);
>> +static int ocfs2_filecheck_repair_inode_block(struct super_block *sb,
>> + struct buffer_head *bh);
>> +
>> void ocfs2_set_inode_flags(struct inode *inode)
>> {
>> unsigned int flags = OCFS2_I(inode)->ip_attr;
>> @@ -127,6 +135,7 @@ struct inode *ocfs2_ilookup(struct super
>> struct inode *ocfs2_iget(struct ocfs2_super *osb, u64 blkno, unsigned
> flags,
>> int sysfile_type)
>> {
>> + int rc = 0;
>> struct inode *inode = NULL;
>> struct super_block *sb = osb->sb;
>> struct ocfs2_find_inode_args args;
>> @@ -161,12 +170,17 @@ struct inode *ocfs2_iget(struct ocfs2_su
>> }
>> trace_ocfs2_iget5_locked(inode->i_state);
>> if (inode->i_state & I_NEW) {
>> - ocfs2_read_locked_inode(inode, &args);
>> + rc = ocfs2_read_locked_inode(inode, &args);
>> unlock_new_inode(inode);
>> }
>> if (is_bad_inode(inode)) {
>> iput(inode);
>> - inode = ERR_PTR(-ESTALE);
>> + if ((flags & OCFS2_FI_FLAG_FILECHECK_CHK) ||
>> + (flags & OCFS2_FI_FLAG_FILECHECK_FIX))
>> + /* Return OCFS2_FILECHECK_ERR_XXX related errno */
>> + inode = ERR_PTR(rc);
>> + else
>> + inode = ERR_PTR(-ESTALE);
>> goto bail;
>> }
>>
>> @@ -494,16 +508,32 @@ static int ocfs2_read_locked_inode(struc
>> }
>>
>> if (can_lock) {
>> - status = ocfs2_read_inode_block_full(inode, &bh,
>> - OCFS2_BH_IGNORE_CACHE);
>> + if (args->fi_flags & OCFS2_FI_FLAG_FILECHECK_CHK)
>> + status = ocfs2_filecheck_read_inode_block_full(inode,
>> + &bh, OCFS2_BH_IGNORE_CACHE, 0);
>> + else if (args->fi_flags & OCFS2_FI_FLAG_FILECHECK_FIX)
>> + status = ocfs2_filecheck_read_inode_block_full(inode,
>> + &bh, OCFS2_BH_IGNORE_CACHE, 1);
>> + else
>> + status = ocfs2_read_inode_block_full(inode,
>> + &bh, OCFS2_BH_IGNORE_CACHE);
>
> NAK, at first glance this is very hacky - I don't like that we've hidden
> these checks
> and fixups down in iget(). If there's a reason it has to be this way that
> should be explained, but otherwise I would expect the check/repair code to
> be less intertwined with ocfs2_iget(). Otherwise I fear we're setting
> ourselves up
> for finding some ugly bugs down the road.
Firstly, I want to read inode block separately, but the feature is working with a online file system,
we can't avoid the inodes cache and the cluster environment, I think that I should not handle a inode
block separately without considering the current inodes cache and potential cluster access from other node.
Then I tried to integrate this light-level online check/fix with iget() function, make the online check/fix
operations is compatible with the inodes cache and the cluster environment.
This is why I use iget() to integrate this feature. if there is a more graceful way to implement this feature,
please help to give some suggestions.
>
> Btw, how does the code handle the case where the inode is already in our
> cache? In that case you'd never get to read_locked_inode()...
This online file check/fix is light-level meta-data block check/fix, the check/fix fields usually correspond
with ocfs2_validate_inode_block(), for more serious problem, we have to use fsck by offline.
If the inode is already in our cache, that means this inode block passed ocfs2_validate_inode_block()
verification during loading inode block from the disk, this inode block is sane, we need not check it again.
Thanks
Gang
>
> Thanks,
> --Mark
>
> --
> Mark Fasheh
next prev parent reply other threads:[~2015-09-01 3:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-26 22:12 [Ocfs2-devel] [patch 23/28] ocfs2: check/fix inode block for online file check akpm at linux-foundation.org
2015-08-31 20:56 ` Mark Fasheh
2015-09-01 3:35 ` Gang He [this message]
2015-09-18 9:22 ` Gang He
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=55E58D7F020000F900013CB4@relay2.provo.novell.com \
--to=ghe@suse.com \
--cc=ocfs2-devel@oss.oracle.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).