Re: [PATCH 16/71] xfs: log refcount intent items

Christoph Hellwig <[email protected]>
Newsgroups gmane.comp.file-systems.xfs.general
Message-ID <[email protected]>
> +	__uint64_t			cui_id;
> +	struct xfs_ail_cursor		cur;
> +	struct xfs_ail			*ailp = log->l_ailp;
> +
> +	cud_formatp = item->ri_buf[0].i_addr;
> +	ASSERT(item->ri_buf[0].i_len == sizeof(struct xfs_cud_log_format));

Should we return -EFSCORRUPTED here instead?

> +	/* XXX: do nothing for now */

What else would be do in the future here?

> +static void
> +xfs_trans_set_refcount_flags(
> +	struct xfs_phys_extent		*refc,
> +	enum xfs_refcount_intent_type	type)
> +{
> +	refc->pe_flags = 0;
> +	switch (type) {
> +	case XFS_REFCOUNT_INCREASE:
> +		refc->pe_flags |= XFS_REFCOUNT_EXTENT_INCREASE;
> +		break;
> +	case XFS_REFCOUNT_DECREASE:
> +		refc->pe_flags |= XFS_REFCOUNT_EXTENT_DECREASE;
> +		break;
> +	case XFS_REFCOUNT_ALLOC_COW:
> +		refc->pe_flags |= XFS_REFCOUNT_EXTENT_ALLOC_COW;
> +		break;
> +	case XFS_REFCOUNT_FREE_COW:
> +		refc->pe_flags |= XFS_REFCOUNT_EXTENT_FREE_COW;
> +		break;

Is there any good reasons to use a type enum in core, but flags on
disk?

> +int
> +xfs_trans_log_finish_refcount_update(
> +	struct xfs_trans		*tp,
> +	struct xfs_cud_log_item		*cudp,
> +	enum xfs_refcount_intent_type	type,
> +	xfs_fsblock_t			startblock,
> +	xfs_extlen_t			blockcount,
> +	struct xfs_btree_cur		**pcur)
> +{
> +	int				error;
> +
> +	/* XXX: leave this empty for now */
> +	error = -EFSCORRUPTED;

Lift might be a lot easier if this patch and "xfs: connect refcount
adjust functions to upper layers" were merged into one.  It's not like
they are testable independently anyway.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.