mirror of
https://git.proxmox.com/git/mirror_zfs.git
synced 2025-01-26 18:04:22 +03:00
dsl_pool: extend comment on DSL Pool Configuration Lock
Based on a conversation with Matt on the OpenZFS Slack. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Signed-off-by: Christian Schwarz <me@cschwarz.com> Closes #11370
This commit is contained in:
parent
1c0bbd52c3
commit
49c482fde3
@ -1270,8 +1270,16 @@ dsl_pool_user_release(dsl_pool_t *dp, uint64_t dsobj, const char *tag,
|
|||||||
* (e.g. it could be destroyed). Therefore you shouldn't do anything to the
|
* (e.g. it could be destroyed). Therefore you shouldn't do anything to the
|
||||||
* dataset except release it.
|
* dataset except release it.
|
||||||
*
|
*
|
||||||
* User-initiated operations (e.g. ioctls, zfs_ioc_*()) are either read-only
|
* Operations generally fall somewhere into the following taxonomy:
|
||||||
* or modifying operations.
|
*
|
||||||
|
* Read-Only Modifying
|
||||||
|
*
|
||||||
|
* Dataset Layer / MOS zfs get zfs destroy
|
||||||
|
*
|
||||||
|
* Individual Dataset read() write()
|
||||||
|
*
|
||||||
|
*
|
||||||
|
* Dataset Layer Operations
|
||||||
*
|
*
|
||||||
* Modifying operations should generally use dsl_sync_task(). The synctask
|
* Modifying operations should generally use dsl_sync_task(). The synctask
|
||||||
* infrastructure enforces proper locking strategy with respect to the
|
* infrastructure enforces proper locking strategy with respect to the
|
||||||
@ -1281,6 +1289,25 @@ dsl_pool_user_release(dsl_pool_t *dp, uint64_t dsobj, const char *tag,
|
|||||||
* information from the dataset, then release the pool and dataset.
|
* information from the dataset, then release the pool and dataset.
|
||||||
* dmu_objset_{hold,rele}() are convenience routines that also do the pool
|
* dmu_objset_{hold,rele}() are convenience routines that also do the pool
|
||||||
* hold/rele.
|
* hold/rele.
|
||||||
|
*
|
||||||
|
*
|
||||||
|
* Operations On Individual Datasets
|
||||||
|
*
|
||||||
|
* Objects _within_ an objset should only be modified by the current 'owner'
|
||||||
|
* of the objset to prevent incorrect concurrent modification. Thus, use
|
||||||
|
* {dmu_objset,dsl_dataset}_own to mark some entity as the current owner,
|
||||||
|
* and fail with EBUSY if there is already an owner. The owner can then
|
||||||
|
* implement its own locking strategy, independent of the dataset layer's
|
||||||
|
* locking infrastructure.
|
||||||
|
* (E.g., the ZPL has its own set of locks to control concurrency. A regular
|
||||||
|
* vnop will not reach into the dataset layer).
|
||||||
|
*
|
||||||
|
* Ideally, objects would also only be read by the objset’s owner, so that we
|
||||||
|
* don’t observe state mid-modification.
|
||||||
|
* (E.g. the ZPL is creating a new object and linking it into a directory; if
|
||||||
|
* you don’t coordinate with the ZPL to hold ZPL-level locks, you could see an
|
||||||
|
* intermediate state. The ioctl level violates this but in pretty benign
|
||||||
|
* ways, e.g. reading the zpl props object.)
|
||||||
*/
|
*/
|
||||||
|
|
||||||
int
|
int
|
||||||
|
Loading…
Reference in New Issue
Block a user