On Mon, Aug 01, 2016 at 01:28:08PM +0800, Wang Xiaoguang wrote:
> v3: we introduce a atomic_t fs_frozen, and if fs_frozen is 1, we can not
> handle delayed iputs.
> v4: change atomic_t fs_frozen to be int.
As it is now, I think the barriers are not needed. The freeze callback
sets it and then does transaction barrier. Ie. either there's no
transaction, or it waits for the commit. At this point any of the
committing threads will notice fs_fozen == 1.
In the worst case, when the check happens between setting to 1 and
barrier:
CPU1 CPU2
fs_frozen = 1
(no barrier, other threads
might still see 0)
if ("is fs_frozen?")
do delay iputs
transaction barrier
wait for the cpu2
transaction
That's not the classic barrier scheme, we don't care if there are other
threads in the middle of a transaction, we'll wait anyway. I'll add a
comment of similar wording.
Reviewed-by: David Sterba <dsterba@xxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html