بخش تخصصی (۳): ‏RADOS‏ — ‏snapshot‏ و ‏clone‏، ‏watch/notify‏ و ‏cls‏ در سمت ‏OSD‏، و مرجع ‏rados‏ و ‏pool‏

۳۶-۱ پیش از شروع#

‏snapshot‏ در ‏RADOS‏ پایه‌ی ‏snapshot‏ در ‏RBD‏ و ‏CephFS‏ است، ‏watch/notify‏ پایه‌ی هماهنگی میان کلاینت‌های ‏RBD‏ و ‏RGW‏، و کلاس‌های شیء (‏cls‏) پایه‌ی بیشتر فراداده‌ی ‏RBD‏ و ‏RGW‏. فصل ۱۴ این سازوکارها را از دید ‏librados‏ و فصل ۱۵ نوشتن یک کلاس را نشان داد. این فصل همان‌ها را درون ‏OSD‏ دنبال می‌کند: ‏SnapSet‏ چگونه تغییر می‌کند، ‏clone‏ چه زمانی ساخته می‌شود، خواندن از ‏snapshot‏ به کدام ‏clone‏ می‌رسد، ‏snaptrim‏ چگونه فضا را آزاد می‌کند، ‏watch‏ و ‏notify‏ چه حالتی در ‏OSD‏ دارند و فراخوانی کلاس چگونه درون همان تراکنش ‏op‏ اجرا می‌شود. فصل با مرجع کامل ‏rados‏ و ‏ceph osd pool‏ تمام می‌شود.

۳۶-۱-۱ این فصل به چه سؤال‌هایی جواب می‌دهد؟#

• ‏snapshot‏ نوع ‏pool‏ و ‏self-managed‏ چه فرقی دارند و چرا نمی‌توان هر دو را روی یک ‏pool‏ داشت؟
• ‏SnapContext‏ چیست و چه کسی آن را می‌فرستد؟
• ‏make_writeable‏ چه زمانی ‏clone‏ می‌سازد و ‏clone_overlap‏ چه چیزی را نشان می‌دهد؟
• خواندن از ‏snap‏ شماره‌ی ۵ به کدام ‏clone‏ می‌رسد؟
• ‏snaptrim‏ پس از حذف ‏snapshot‏ چه می‌کند و ‏SnapMapper‏ چه کلیدهایی دارد؟
• ‏watch‏ در ‏OSD‏ چه زمانی منقضی می‌شود و ‏notify‏ کی کامل می‌شود؟
• فراخوانی ‏cls‏ چگونه با بقیه‌ی ‏op‏های یک پیام در یک تراکنش اتمی می‌نشیند؟

۳۶-۱-۲ پیش‌نیاز#

فصل ۱۴ (‏librados‏، ‏watch/notify‏)، فصل ۱۵ (‏cls‏)، فصل ۳۴ (‏object_info_t‏، ‏SnapSet‏، مسیر ‏op‏).

۳۶-۲ دو نوع ‏snapshot‏#

هر دو نوع از یک شمارنده‌ی ‏snap_seq‏ در ‏pool‏ شماره می‌گیرند. اگر هر دو روی یک ‏pool‏ فعال باشند، مالکیت شماره‌ها نامعلوم می‌شود. به همین دلیل ‏mon‏ پس از اولین استفاده از یک نوع، نوع دیگر را رد می‌کند. ‏pool‏‌ی که ‏RBD‏ از آن استفاده می‌کند نباید ‏pool snapshot‏ داشته باشد.

‏SnapContext‏ دو چیز دارد: ‏seq‏ (بزرگ‌ترین شماره‌ی ‏snapshot‏ که نویسنده از آن خبر دارد) و ‏snaps‏ (فهرست ‏snapshot‏های زنده، به ترتیب نزولی). ‏RBD‏ آن را در ‏header‏ تصویر نگه می‌دارد و ‏librbd‏ در هر نوشتن روی اشیای داده آن را می‌فرستد (فصل ۳۷).

۳۶-۳ ‏SnapSet‏ و ‏clone‏#

۳۶-۳-۱ فیلدهای ‏SnapSet‏#

‏SnapSet‏ در ‏xattr‏ ‏‏snapset‏ روی شیء ‏head‏ (فصل ۳۴) ذخیره می‌شود:

‏clone‏ خودش یک شیء ‏RADOS‏ با همان نام و ‏hash‏ ولی ‏snap‏ برابر شماره‌ی ‏clone‏ است. در ‏BlueStore‏ این ‏clone‏ با کپی منطقی (‏clone‏ کردن ‏extent‏ها با شمارنده‌ی ارجاع در ‏shared blob‏، فصل ۲۴) ساخته می‌شود، پس ساختن آن ارزان است و فقط بخش‌هایی که بعداً بازنویسی می‌شوند فضای تازه می‌گیرند.

۳۶-۳-۲ ساختن ‏clone‏ هنگام نوشتن#

pseudocode
make_writeable(ctx, snapc):
    if snapc.seq < snapset.seq: use snapset's newer context        # کلاینت قدیمی
    if head exists and not whiteout and snapc.snaps not empty
       and snapc.snaps[0] > snapset.seq:                           # snap تازه از آخرین نوشتن
        snaps = [s in snapc.snaps where s > snapset.seq]           # نزولی
        coid = head with snap = snapc.seq
        _make_clone(head → coid)                                   # clone در ObjectStore
        snapset.clones.push_back(coid.snap)
        snapset.clone_snaps[coid.snap] = snaps
        snapset.clone_size[coid.snap]  = head.size
        snapset.clone_overlap[coid.snap] = [0, head.size)
        log CLONE entry ; at_version.version++
    if snapset.clones not empty:
        clone_overlap[newest clone] -= modified_ranges(ctx)        # بخش بازنویسی‌شده دیگر مشترک نیست
    snapset.seq = max(snapset.seq, snapc.seq)

مثال عددی. شیء ‏rbd_data.5f3a.0000000000000000‏ با اندازه‌ی ۴ ‏MiB‏ است و ‏snapset.seq = 0‏.

1. ۱. ‏snapshot‏ شماره‌ی ۴ گرفته می‌شود. ‏librbd‏ با ‏SnapContext‏ ‏‏{seq: 4, snaps: [4]}‏ بازه‌ی ‏[0, 64K)‏ را می‌نویسد. چون ۴ > ۰، ‏clone‏ ‏‏@4‏ ساخته می‌شود: ‏clone_snaps[4] = [4]‏، ‏clone_size[4] = 4 MiB‏ و پس از نوشتن ‏clone_overlap[4] = [64K, 4M)‏. ‏‏seq‏ برابر ۴ می‌شود.
2. ۲. ‏snapshot‏های ۵ و ۶ گرفته می‌شوند. نوشتن ‏[1M, 1M+64K)‏ با ‏{seq: 6, snaps: [6,5,4]}‏ می‌آید. چون ۶ > ۴، ‏clone‏ ‏‏@6‏ با ‏clone_snaps[6] = [6,5]‏ ساخته می‌شود و ‏clone_overlap[6] = [0,1M) ∪ [1M+64K, 4M)‏.
3. ۳. نوشتن بعدی با همان ‏SnapContext‏ دیگر ‏clone‏ نمی‌سازد (۶ > ۶ نیست) و فقط ‏clone_overlap[6]‏ را کوچک‌تر می‌کند.

فضای واقعی ‏clone‏ ‏‏@4‏ برابر بخشی است که در ‏head‏ یا ‏clone‏های جدیدتر بازنویسی شده، یعنی ۴‏M‏ منهای اندازه‌ی ‏clone_overlap[4]‏؛ در این مثال ۶۴ ‏KiB‏. ‏ceph df‏ و ‏rbd du‏ همین حساب را انجام می‌دهند.

۳۶-۳-۳ خواندن از ‏snapshot‏#

pseudocode
find_object_context(oid with snap = s):
    if s == NOSNAP: return head
    ss = snapset of head
    if s > ss.seq: return head                         # شیء پس از s تغییر نکرده
    k = first index with ss.clones[k] >= s
    if none: ENOENT                                    # شیء پس از s ساخته شده است
    clone = ss.clones[k]
    if clone is missing: EAGAIN (wait for recovery)
    if s not in ss.clone_snaps[clone]: ENOENT          # در زمان s شیء وجود نداشت
    if s in removed_snaps_queue of pool: ENOENT        # snap در حال حذف
    return clone

در مثال بالا: خواندن در ‏snap 5‏ به ‏clones = [4, 6]‏ می‌رسد. اولین ‏clone‏ ‏≥ ۵ ‏‏@6‏ است و ۵ در ‏clone_snaps[6] = [6,5]‏ هست، پس ‏@6‏ خوانده می‌شود. خواندن در ‏snap 7‏ (بزرگ‌تر از ‏seq=6‏) مستقیم ‏head‏ را برمی‌گرداند. خواندن در ‏snap 3‏ به ‏@4‏ می‌رسد ولی ۳ در ‏[4]‏ نیست، پس ‏ENOENT‏ می‌گیرد، چون شیء در ‏snap 3‏ هنوز وجود نداشته است.

۳۶-۳-۴ حذف ‏head‏ و ‏whiteout‏#

اگر ‏head‏ حذف شود ولی ‏clone‏هایی داشته باشد، ‏OSD‏ نمی‌تواند ‏SnapSet‏ را دور بریزد. در این حالت ‏head‏ به‌صورت ‏whiteout‏ می‌ماند: شیئی با پرچم ‏whiteout‏ در ‏object_info_t‏ که برای کلاینت وجود ندارد (‏stat‏ آن ‏ENOENT‏ می‌دهد) ولی ‏SnapSet‏ را نگه می‌دارد. پس از آنکه ‏snaptrim‏ آخرین ‏clone‏ را پاک کند، ‏whiteout‏ هم حذف می‌شود.

۳۶-۴ ‏snaptrim‏ و ‏SnapMapper‏#

۳۶-۴-۱ حذف ‏snapshot‏#

حذف یک ‏snapshot‏ در ‏mon‏ فقط شماره‌ی آن را به ‏removed_snaps_queue‏ ‏pool‏ اضافه می‌کند (و در ‏OSDMap‏ به ‏new_removed_snaps‏). هر ‏PG‏ که نقشه‌ی تازه را می‌بیند، آن ‏snap‏ را به ‏snap_trimq‏ خود اضافه می‌کند و ماشین حالت ‏SnapTrimmer‏ شروع به کار می‌کند. وقتی همه‌ی ‏PG‏ها کار را تمام کردند، ‏mon‏ آن را در ‏purged_snaps‏ ثبت می‌کند.

برای پیدا کردن ‏clone‏هایی که یک ‏snap‏ دارند، پیمایش همه‌ی اشیا گران است. ‏SnapMapper‏ یک نمایه‌ی معکوس در ‏omap‏ شیء ‏snapmapper‏ در مجموعه‌ی ‏meta‏ هر ‏OSD‏ نگه می‌دارد:

‏hobject_t::to_str()‏ قالب ‏<pool:016X>.<nibble-reversed hash:08X>.<snap>.<name>.<key>.<nspace>‏ دارد. برای ‏clone‏ ‏‏@6‏ شیء مثال ما در ‏pool‏ ‏۳ با ‏hash‏ ‏‏0x8c7e1b1f‏، کلید ‏SNA‏ برای ‏snap 5‏ چنین است:

مثال:
SNA_3_0000000000000005_0000000000000003.F1B1E7C8.6.rbd_data.5f3a.0000000000000000..

کلید با پیشوند ‏SNA_3_0000000000000005_‏ شروع می‌شود، پس همه‌ی ‏clone‏های ‏snap 5‏ در ‏pool‏ ‏۳ با یک اسکن بازه‌ای پیدا می‌شوند. برای ‏EC‏، پیشوند ‏shard‏ (مثلاً ‏.2_‏) هم اضافه می‌شود؛ برای ‏replicated‏ خالی است.

pseudocode
for coid in snapmapper.get_next_objects_to_trim(snap, max):
    new_snaps = clone_snaps[coid] minus (snaps removed or queued for removal)
    if new_snaps empty:                                  # clone دیگر لازم نیست
        if coid is not the oldest clone:
            clone_overlap[older] = clone_overlap[older] ∩ clone_overlap[coid]
        delete coid ; log DELETE
        remove coid from clones, clone_overlap, clone_size, clone_snaps
    else:
        clone_snaps[coid] = new_snaps ; log MODIFY (snapmapper update)
    if head is whiteout and clones empty: delete head
    write new snapset to head

با ‏mClock‏، ‏snaptrim‏ یکی از کلاس‌های پس‌زمینه است و اولویت آن از ‏profile‏ می‌آید (فصل ۲۱). حالت ‏snaptrim_wait‏ و ‏snaptrim‏ در ‏ceph pg ls‏ و پرچم ‏nosnaptrim‏ در ‏ceph osd set‏ برای کنترل آن به کار می‌روند.

۳۶-۵ ‏watch‏ و ‏notify‏ در ‏OSD‏#

‏watch‏ یک حالت روی شیء است: در ‏object_info_t.watchers‏ ثبت می‌شود (پس با شیء تکثیر و پس از تغییر ‏primary‏ حفظ می‌شود)، و روی ‏primary‏ یک شیء ‏Watch‏ با اتصال کلاینت و تایمر دارد. زیرعملیات‌ها در ‏CEPH_OSD_OP_WATCH‏ با کدهای ‏WATCH‏ (۳)، ‏RECONNECT‏ (۵)، ‏PING‏ (۷) و ‏UNWATCH‏ (۰) مشخص می‌شوند.

pseudocode
watch(cookie, timeout = osd_client_watch_timeout):     # پیش‌فرض 30 ثانیه
    oi.watchers[(client, cookie)] = watch_info ; persist with object
    Watch.connect(con) ; register timeout callback
ping every few seconds → Watch.got_ping(now) → reset timer
timer fires (no ping) → remove watch from oi.watchers (یک نوشتن روی شیء)
notify(payload, timeout = osd_default_notify_timeout):  # پیش‌فرض 30 ثانیه
    for each watch on object: send MWatchNotify(NOTIFY) ; Notify.start_watcher
    each watcher acks (notify_ack with reply payload) → complete_watcher
    if all acked or timed_out:
        reply MWatchNotify(NOTIFY_COMPLETE, data = {replies, missed watchers})
        return_code = -ETIMEDOUT if timed_out

نکته‌ی عملی: ‏watch‏ منقضی‌شده با یک نوشتن روی شیء حذف می‌شود، پس اگر شیء در ‏PG‏ای باشد که نوشتن را نمی‌پذیرد (‏PG‏ فعال نیست، شیء ‏degraded‏ است یا ‏scrub‏ نوشتن را مسدود کرده)، حذف به تعویق می‌افتد و ‏watch‏ مرده تا آن زمان در فهرست می‌ماند. ‏rados listwatchers‏ و ‏rbd status‏ همین فهرست را از ‏object_info_t‏ می‌خوانند.

# مثال: دیدن watcherها و ارسال یک notify آزمایشی
rados -p rbd listwatchers rbd_header.5f3a2b8c1d4e
rados -p rbd notify rbd_header.5f3a2b8c1d4e hello

مثال (خروجی):
watcher=10.20.0.31:0/2846217731 client.24183 cookie=94823571521536

۳۶-۶ فراخوانی ‏cls‏ در سمت ‏OSD‏#

‏op‏ی با کد ‏CEPH_OSD_OP_CALL‏ نام کلاس، نام متد و ورودی را دارد. ‏do_osd_ops‏ کلاس را از ‏ClassHandler‏ می‌گیرد (اگر لازم باشد، ‏libcls_<name>.so‏ را از ‏osd_class_dir‏ بارگذاری می‌کند) و متد را با یک ‏cls_method_context_t‏ صدا می‌زند که در واقع همان ‏OpContext‏ است.

pseudocode
case CALL(class, method, indata):
    cls = ClassHandler.open_class(class)         # بارگذاری فقط اگر در osd_class_load_list باشد
    m = cls.get_method(method)
    check caps: m.flags RD → نیاز به r یا class-read ; WR → w یا class-write
    r = m.exec(ctx, indata, outdata)
       # درون متد: cls_cxx_read / cls_cxx_write / cls_cxx_map_set_vals / ...
       # هر کدام do_osd_ops(ctx, [one op]) را روی همان ctx صدا می‌زند
    if r < 0: whole message fails → no transaction applied
    outdata → reply

چون متد روی همان ‏OpContext‏ کار می‌کند، همه‌ی تغییرهای آن با بقیه‌ی ‏op‏های همان پیام در یک تراکنش و یک ورودی ‏log‏ می‌نشینند و اتمی‌اند. به همین دلیل ‏RBD‏ و ‏RGW‏ منطق‌هایی مثل «اگر کلید وجود ندارد، بساز و شمارنده را افزایش بده» را در کلاس پیاده می‌کنند.

کلاس‌های دیگری مثل ‏cas‏ یا ‏2pc_queue‏ و ‏queue‏ (که ‏RGW‏ برای ‏gc‏ و اعلان‌ها استفاده می‌کند) با بسته‌ها نصب می‌شوند ولی در این فهرست‌ها نیستند. فهرست واقعی در توزیع شما ممکن است متفاوت باشد؛ با ‏ceph config get osd osd_class_load_list‏ بررسی کنید.

۳۶-۷ مرجع ‏rados‏#

۳۶-۷-۱ دستورهای ‏pool‏ و شیء#

در جدول‌های این فصل و فصل‌های بعد، ‏{a,b}‏ یعنی «یکی از ‏a‏ یا ‏b‏» و ‏P‏، ‏O‏ و ‏S‏ به‌ترتیب نام ‏pool‏، شیء و ‏snapshot‏ هستند.

# مثال: cloneهای یک شیء RBD
rados -p rbd listsnaps rbd_data.5f3a.0000000000000000

مثال (خروجی):
rbd_data.5f3a.0000000000000000 (seq:6):
cloneid	snaps	size	overlap
4	4	4194304	[65536~4128768]
6	5,6	4194304	[0~1048576,1114112~3080192]
head	-	4194304

‏overlap‏ با قالب ‏[offset~length]‏ نشان داده می‌شود: ‏65536~4128768‏ همان ‏[64K, 4M)‏ است.

۳۶-۸ مرجع ‏ceph osd pool‏#

مثال (بخشی از ceph osd pool ls detail):
pool 3 'rbd' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32
  autoscale_mode on last_change 1462 lfor 0/0/980 flags hashpspool,selfmanaged_snaps stripe_width 0
  application rbd

‏min_size‏ پیش‌فرض صفر است که یعنی ‏size − size/2‏؛ برای ‏size=3‏ همان ۲.

۳۶-۹ تنظیم و عیب‌یابی#

• ‏snaptrim‏ کند و فضای آزادنشده: ‏ceph pg ls snaptrim_wait‏ را ببینید. روی ‏HDD‏، ‏osd_snap_trim_sleep_hdd‏ را با احتیاط کم کنید یا ‏profile mClock‏ را برای مدتی به ‏high_recovery_ops‏ ببرید.
• کندی پس از گرفتن ‏snapshot‏: نخستین نوشتن روی هر شیء پس از ‏snapshot‏ یک ‏clone‏ می‌سازد و فراداده‌ی بیشتری می‌نویسد. گرفتن ‏snapshot‏ بسیار پرتکرار روی تصویر پرنوشتن باعث تعداد زیادی ‏clone‏ و ‏SnapMapper‏ بزرگ می‌شود.
• ‏rados ls‏ شیئی را نشان می‌دهد ولی ‏stat‏ آن ‏ENOENT‏ است: احتمالاً ‏head whiteout‏ است و ‏clone‏ها هنوز ‏trim‏ نشده‌اند.
• ‏watch‏ مرده روی ‏header‏ تصویر ‏RBD‏: ‏rbd status‏ و ‏rados listwatchers‏ را ببینید. اگر کلاینت واقعاً مرده است، پس از ‏osd_client_watch_timeout‏ خودبه‌خود حذف می‌شود. برای قطع فوری، ‏ceph osd blocklist add‏ آدرس آن کلاینت را مسدود می‌کند.
• ‏EOPNOTSUPP‏ در فراخوانی کلاس: کلاس در ‏osd_class_load_list‏ نیست یا فایل ‏.so‏ آن نصب نشده است.

۳۶-۱۰ تکمیلی و به‌روز#

• از ‏Octopus‏ به بعد، ‏OSDMap‏ فهرست کامل ‏removed_snaps‏ را نگه نمی‌دارد و به‌جای آن ‏removed_snaps_queue‏ و ‏purged_snaps‏ (و کلیدهای ‏PSN_‏ در ‏SnapMapper‏) به کار می‌روند. ‏cluster‏های قدیمی‌تر رفتار دیگری داشتند.
• در شاخه‌ی ‏main‏، کپی ‏clone‏ها در مهاجرت ‏pool‏ (‏pool_migration‏) استثنای خودش را در به‌روزرسانی ‏clone_overlap‏ دارد.
• ‏Crimson snapshot‏ و ‏snaptrim‏ را با همان ‏SnapSet‏ و ‏SnapMapper‏ پیاده کرده است (‏crimson/osd/osd_operations/snaptrim_event.cc‏).

۳۶-۱۱ تمرین عملی#

1. ۱. روی یک ‏pool‏ آزمایشی (نه ‏pool‏ ‏‏RBD‏) یک شیء بنویسید، ‏rados mksnap s1‏ بگیرید، بخشی از شیء را بازنویسی کنید و ‏listsnaps‏ را بخوانید. سپس ‏rados -s s1 get‏ را با نسخه‌ی جاری مقایسه کنید.
2. ۲. یک تصویر ‏RBD‏ بسازید، سه ‏snapshot‏ بگیرید و میان آن‌ها بنویسید؛ با ‏rados listsnaps‏ روی یکی از اشیای داده، ‏clone_snaps‏ و ‏overlap‏ را با محاسبه‌ی دستی تطبیق دهید.
3. ۳. ‏snapshot‏ میانی را حذف کنید و در ‏ceph pg ls snaptrim‏ و دوباره در ‏listsnaps‏ اثر آن را ببینید.
4. ۴. در دو ترمینال ‏rados watch‏ و ‏rados notify‏ را اجرا کنید؛ سپس فرایند ‏watch‏ را با ‏kill -STOP‏ متوقف و زمان حذف شدنش از ‏listwatchers‏ را اندازه بگیرید.

۳۶-۱۲ پرسش‌های مرور#

1. ۱. چرا یک ‏pool‏ نمی‌تواند هم ‏pool snapshot‏ و هم ‏self-managed snapshot‏ داشته باشد؟
2. ۲. ‏SnapContext‏ چه فیلدهایی دارد و در ‏RBD‏ چه کسی آن را می‌فرستد؟
3. ۳. شرط ساختن ‏clone‏ در ‏make_writeable‏ چیست؟
4. ۴. ‏clone‏ با چه شماره‌ای نام‌گذاری می‌شود؟
5. ۵. در مثال فصل، خواندن در ‏snap 5‏ و ‏snap 3‏ به چه نتیجه‌ای می‌رسد؟
6. ۶. ‏whiteout‏ چیست و چه زمانی حذف می‌شود؟
7. ۷. کلید ‏SNA_‏ در ‏SnapMapper‏ چه ساختاری دارد و چرا به این شکل است؟
8. ۸. وقتی ‏clone‏ دیگر هیچ ‏snap‏ی ندارد، با ‏clone_overlap‏ چه می‌شود؟
9. ۹. ‏watch‏ منقضی‌شده چگونه حذف می‌شود و چرا ممکن است تا مدتی بماند؟
10. ۱۰. چرا فراخوانی ‏cls‏ با بقیه‌ی ‏op‏های یک پیام اتمی است؟

پاسخ این پرسش‌ها در پیوست ه: پاسخ پرسش‌ها آمده است. پاسخ پرسش‌های این فصل →

۳۶-۱۳ منابع این فصل#

• ‏PrimaryLogPG.cc‏ (make_writeable، ‏find_object_context‏، ‏trim_object‏، ‏CALL‏
  https://github.com/ceph/ceph/blob/main/src/osd/PrimaryLogPG.cc
• ‏SnapMapper.cc‏
  https://github.com/ceph/ceph/blob/main/src/osd/SnapMapper.cc
• ‏Watch.cc‏
  https://github.com/ceph/ceph/blob/main/src/osd/Watch.cc
• ‏osd_types.h‏ (SnapSet
  https://github.com/ceph/ceph/blob/main/src/osd/osd_types.h
• ‏rados.cc‏ (فهرست دستورهای ‏rados‏
  https://github.com/ceph/ceph/blob/main/src/tools/rados/rados.cc
• مستند توسعه‌دهنده درباره‌ی ‏snapshot‏
  https://docs.ceph.com/en/latest/dev/osd_internals/snaps/
• مستند ‏watch/notify‏
  https://docs.ceph.com/en/latest/dev/osd_internals/watch_notify/
• مرجع ‏pool‏
  https://docs.ceph.com/en/latest/rados/operations/pools/