[PATCH] Btrfs: no full sync flag on new inode when we do not reuse inode id

[PATCH] Btrfs: no full sync flag on new inode when we do not reuse inode id

[Liu Bo]

When we are not with inode_cache option, we won't reuse inode id, which
means all of inodes will own different inode id, thus we don't worry
about "reuse of inode id leads to log tree's corruption" thing.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
---
 fs/btrfs/inode.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 95542a1..8f41ffd 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4717,7 +4717,9 @@ static struct inode *btrfs_new_inode(struct btrfs_trans_handle *trans,
 	 * sync since it will be a full sync anyway and this will blow away the
 	 * old info in the log.
 	 */
-	set_bit(BTRFS_INODE_NEEDS_FULL_SYNC, &BTRFS_I(inode)->runtime_flags);
+	if (btrfs_test_opt(root, INODE_MAP_CACHE))
+		set_bit(BTRFS_INODE_NEEDS_FULL_SYNC,
+			&BTRFS_I(inode)->runtime_flags);
 
 	if (S_ISDIR(mode))
 		owner = 0;
-- 
1.7.7.6

Re: [PATCH] Btrfs: no full sync flag on new inode when we do not reuse inode id

[Josef Bacik]

On Thu, Dec 06, 2012 at 08:11:54PM -0700, Liu Bo wrote:
> When we are not with inode_cache option, we won't reuse inode id, which
> means all of inodes will own different inode id, thus we don't worry
> about "reuse of inode id leads to log tree's corruption" thing.
> 
> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>

With the new fsync stuff I have I still need to make sure all new xattrs and
such are on disk so this needs to stay the way it is.  Thanks,

Josef

Re: [PATCH] Btrfs: no full sync flag on new inode when we do not reuse inode id

[Liu Bo]

On Tue, Dec 11, 2012 at 10:01:17AM -0500, Josef Bacik wrote:
> On Thu, Dec 06, 2012 at 08:11:54PM -0700, Liu Bo wrote:
> > When we are not with inode_cache option, we won't reuse inode id, which
> > means all of inodes will own different inode id, thus we don't worry
> > about "reuse of inode id leads to log tree's corruption" thing.
> > 
> > Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> 
> With the new fsync stuff I have I still need to make sure all new xattrs and
> such are on disk so this needs to stay the way it is.  Thanks,

So with new fsync we cannot bare any old items even if their keys's
objectid(actually inode id) are different, is it right?

Actually I made this patch to try to skip the expensive committing
transaction in a 'create & write & fsync' test. 

thanks,
liubo

Re: [PATCH] Btrfs: no full sync flag on new inode when we do not reuse inode id

[Josef Bacik]

On Tue, Dec 11, 2012 at 06:43:04PM -0700, Liu Bo wrote:
> On Tue, Dec 11, 2012 at 10:01:17AM -0500, Josef Bacik wrote:
> > On Thu, Dec 06, 2012 at 08:11:54PM -0700, Liu Bo wrote:
> > > When we are not with inode_cache option, we won't reuse inode id, which
> > > means all of inodes will own different inode id, thus we don't worry
> > > about "reuse of inode id leads to log tree's corruption" thing.
> > > 
> > > Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> > 
> > With the new fsync stuff I have I still need to make sure all new xattrs and
> > such are on disk so this needs to stay the way it is.  Thanks,
> 
> So with new fsync we cannot bare any old items even if their keys's
> objectid(actually inode id) are different, is it right?
> 

No its more that I need to know that I should log everything related to the
inode, xattrs and all.  Otherwise I'll just log the inode item and make selinux
very sad.  Thanks,

Josef

Re: [PATCH] Btrfs: no full sync flag on new inode when we do not reuse inode id

[Liu Bo]

On Wed, Dec 12, 2012 at 09:50:04AM -0500, Josef Bacik wrote:
> On Tue, Dec 11, 2012 at 06:43:04PM -0700, Liu Bo wrote:
> > On Tue, Dec 11, 2012 at 10:01:17AM -0500, Josef Bacik wrote:
> > > On Thu, Dec 06, 2012 at 08:11:54PM -0700, Liu Bo wrote:
> > > > When we are not with inode_cache option, we won't reuse inode id, which
> > > > means all of inodes will own different inode id, thus we don't worry
> > > > about "reuse of inode id leads to log tree's corruption" thing.
> > > > 
> > > > Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> > > 
> > > With the new fsync stuff I have I still need to make sure all new xattrs and
> > > such are on disk so this needs to stay the way it is.  Thanks,
> > 
> > So with new fsync we cannot bare any old items even if their keys's
> > objectid(actually inode id) are different, is it right?
> > 
> 
> No its more that I need to know that I should log everything related to the
> inode, xattrs and all.  Otherwise I'll just log the inode item and make selinux
> very sad.  Thanks,
> 
> Josef

Oh, I see, I've mixed with another different problem, sorry.

thanks,
liubo