菜单
Use when a host or guest (VM/container) using LVM thin-provisioned storage shows ENOSPC, read-only remounts, or stalled writes despite the filesystem reporting free space — covers layered diagnosis and safe recovery of the thin pool and any affected filesystems.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Use when implementing multiple related enhancements, or a large feature that must be split across risk boundaries, and you need to decide branch/PR structure. Covers accumulating related work on one shared branch with atomic commits per enhancement, splitting risky multi-PR features along risk seams, and safely handling a branch that has both committed and dirty (uncommitted) work when shipping.
Use when a rebase or merge reports conflicts on a file where both branches only appended or inserted new content (append-only logs, registries, holding-pen documents) rather than editing the same lines. Recognizes the conflict as a false signal and resolves it as a union-keep-both operation instead of a real semantic merge.
Use when reskinning an app with a real brand's visual identity — extract the actual palette from a live site's raw CSS (not markdown), recreate logo/icon assets programmatically with documented extraction rationale, and codify everything as versioned, named design tokens rather than one-off hardcoded values.
Use when building a skill, doc, or knowledge base for an existing internal service or codebase, or when asked to audit past sessions for recurring failures and gaps — mine prior Claude conversation transcripts instead of reverse-engineering from logs or current code alone.
| name | lvm-thin-pool-diagnostics-recovery |
| description | Use when a host or guest (VM/container) using LVM thin-provisioned storage shows ENOSPC, read-only remounts, or stalled writes despite the filesystem reporting free space — covers layered diagnosis and safe recovery of the thin pool and any affected filesystems. |
| status | active |
| version | "2026-07-05T00:00:00.000Z" |
df) but writes fail with ENOSPC or the filesystem has gone read-only.out-of-data-space error IO mode).1. Diagnose in layers — never trust filesystem-level free space alone.
df can show "free" space that is meaningless if the backing thin pool can't allocate new blocks. Every write will fail with ENOSPC regardless of what df reports.lvs to see true thin-pool utilization, and dmesg to check for out-of-data-space error IO mode — this is the pool refusing all new allocations fleet-wide, threatening every thin-backed guest, not just the one you're debugging.errors=remount-ro behavior can leave it in emergency_ro even after the underlying pool issue is fixed.2. Recover the pool first, then the filesystem, then reclaim space.
lvextend -L+<sizeG> pve/data. The pool exits error-IO mode once resumed.mount | grep rw; if it still shows ro, a bare mount -o remount,rw will be rejected because the ext4 superblock error flag persists.e2fsck on the volume, then restart it.fstrim from the host against the guest (e.g. pct fstrim <ctid> for Proxmox containers) — an unprivileged fstrim run inside the guest itself will fail; the privileged host-side call succeeds. The reclaimed headroom is what allows a clean reinstall of any packages that were corrupted mid-write during the original failure.3. Diagnose write stalls separately from full-pool ENOSPC.
Thin-pool writes can silently stall under metadata pressure (not just data-space pressure) at predictable thresholds, blocking streaming operations without an outright error. To confirm: use iostat to check I/Os-in-progress, sample /proc/diskstats over time, and correlate against live-mirror/replication activity. If confirmed, recover by draining the near-full pool onto a healthy one using idempotent offline moves — never online moves while under pressure — and force-stop the guest/service before moving, to prevent new writes from cascading into the source pool mid-drain.
lvs/dmesg on the host before ruling out the pool.remount,rw after fixing the pool will not clear an emergency_ro ext4 volume — you need e2fsck first.fstrim unprivileged from inside the guest expecting it to reclaim space — it silently fails or no-ops; it must run privileged from the host.lvs shows healthy headroom before considering the incident closed.