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

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html