Re: [PATCH v4] btrfs: fix fsfreeze hang caused by delayed iputs deal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux