| Message ID | 1354849914-14123-1-git-send-email-bo.li.liu@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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;
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(-)