From: Timothy Shimmin <tes@sgi.com>
To: Niv Sardi <xaiki@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: [PATCH] Introduce xfs_trans_bmap_add_attrfork.
Date: Wed, 02 Jul 2008 18:25:26 +1000 [thread overview]
Message-ID: <486B3B76.8020303@sgi.com> (raw)
In-Reply-To: <nccy74r1oba.fsf@sgi.com>
Niv Sardi wrote:
> Updated patch attached,
> Moved case where there is no transaction back into
> xfs_bmap_add_attrfork() and rely on caller to call xfs_trans_roll(),
>
> Christoph Hellwig <hch@infradead.org> writes:
>>> +xfs_bmap_add_attrfork(
> [...]
>> Care to add this below xfs_trans_bmap_add_attrfork? Also please
>> us struct xfs_inode instead of the typedef.
>
> Done,
>
>>> + if (tpp) {
>>> + ASSERT(*tpp);
>>> + tp = *tpp;
>>> + } else {
> [...]
>> I think it would be much cleaner if all the transaction setup, joining
>> etc was done in xfs_bmap_add_attrfork, and xfs_trans_bmap_add_attrfork
>> just gets an always non-NULL xfs_trans pointer. That would mean
>> the common code would become just a helper, and
>> xfs_trans_bmap_add_attrfork would be a small wrapper including the
>> xfs_trans_roll. Alternatively the caller could always do the roll.
>
> I think I got it right, but error handeling is a bit weird this way,
> looks logically identical.
>
>
>
> ------------------------------------------------------------------------
>
>
> Thanks for this extensive review =)
>
> + if (error)
> + goto error1;
> +
> + if (XFS_IFORK_Q(ip))
> + goto error1;
> +
> + ASSERT(ip->i_d.di_anextents == 0);
> + VN_HOLD(XFS_ITOV(ip));
> + xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL);
> + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE);
> +
> + error = xfs_trans_bmap_add_attrfork(NULL, ip, size, rsvd);
> + if (error)
> + return error;
> + return xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES);
I was kind of expecting the transaction, &tp, to be passed into
xfs_trans_bmap_add_attrfork().
(And then xfs_trans_bmap_add_attrfork() which calls
xfs_bmap_finish() which calls xfs_trans_dup() and so from that
point on we would then have to update tp if we were to use it.)
So how come we pass in NULL?
I'm tired so I'm probably missing something obvious.
--Tim
next prev parent reply other threads:[~2008-07-02 8:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 4:42 [RFC] Create with EA initial work Niv Sardi
2008-06-23 4:42 ` [PATCH] Move attr log alloc size calculator to another function Niv Sardi
2008-06-23 4:42 ` [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Niv Sardi
2008-06-23 4:42 ` [PATCH] Introduce xfs_trans_bmap_add_attrfork Niv Sardi
2008-06-23 4:42 ` [PATCH] Give a transaction to xfs_attr_set_int Niv Sardi
2008-06-29 22:08 ` Dave Chinner
2008-07-01 15:49 ` Josef 'Jeff' Sipek
2008-06-26 9:28 ` [PATCH] Introduce xfs_trans_bmap_add_attrfork Christoph Hellwig
2008-06-27 4:42 ` Niv Sardi
2008-07-02 8:25 ` Timothy Shimmin [this message]
2008-07-02 23:39 ` Niv Sardi
2008-06-29 22:02 ` Dave Chinner
2008-06-26 8:28 ` [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Christoph Hellwig
2008-06-27 4:44 ` Niv Sardi
2008-06-27 13:03 ` Christoph Hellwig
2008-06-27 13:03 ` Christoph Hellwig
2008-07-02 7:14 ` Timothy Shimmin
2008-06-26 8:24 ` [PATCH] Move attr log alloc size calculator to another function Christoph Hellwig
2008-06-27 4:49 ` Niv Sardi
2008-07-02 6:38 ` Timothy Shimmin
2008-07-10 7:39 ` [UPDATED RFC] Create with EA initial work Niv Sardi
2008-07-10 7:39 ` [PATCH] Move attr log alloc size calculator to another function Niv Sardi
2008-07-10 7:39 ` [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Niv Sardi
2008-07-10 7:39 ` [PATCH] Introduce xfs_bmap_add_attrfork_trans Niv Sardi
2008-07-10 7:39 ` [PATCH] Give a transaction to xfs_attr_set_int Niv Sardi
2008-07-11 5:38 ` [PATCH] Export xfs_attr_set_int_trans Niv Sardi
2008-07-11 5:38 ` [PATCH] hack to test create + ea Niv Sardi
2008-07-22 4:43 ` [PATCH] Export xfs_attr_set_int_trans Christoph Hellwig
2008-07-22 6:06 ` Niv Sardi
2008-07-23 7:46 ` Christoph Hellwig
2008-07-11 5:44 ` [PATCH] Give a transaction to xfs_attr_set_int Niv Sardi
2008-07-11 5:59 ` Christoph Hellwig
2008-07-23 7:58 ` [PATCH] Introduce xfs_bmap_add_attrfork_trans Christoph Hellwig
2008-07-22 4:38 ` [UPDATED RFC] Create with EA initial work Christoph Hellwig
2008-07-23 5:35 ` Niv Sardi
2008-07-23 7:51 ` Christoph Hellwig
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=486B3B76.8020303@sgi.com \
--to=tes@sgi.com \
--cc=hch@infradead.org \
--cc=xaiki@sgi.com \
--cc=xfs@oss.sgi.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