ocfs2-devel.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
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

  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).