fs freeze 完整行为分析：能否保证数据落到后端 Host 文件

frozen 状态 (sb->s_writers.frozen)：
  SB_UNFROZEN (0)
       │
       ▼  拿 sb->s_umount 写锁
  SB_FREEZE_WRITE (1)
       │  ① percpu_down_write(rw_sem[0])   ← 阻塞新的 write/mkdir/rename/ioctl
       │     等所有 in-flight 写者释放读锁（含 AIO/io_uring/DIO）
       │
       ▼
  SB_FREEZE_PAGEFAULT (2)
       │  ② percpu_down_write(rw_sem[1])   ← 阻塞新的写 page fault
       │     等所有正在处理的 pagefault 完成
       │
       │  ③ sync_filesystem(sb)             ← 关键：刷脏 + 等 IO + 下 FLUSH
       │
       ▼
  SB_FREEZE_FS (3)
       │  ④ percpu_down_write(rw_sem[2])   ← 阻塞 FS 内部事务
       │  ⑤ sb->s_op->freeze_fs(sb)         ← FS 私有钩子（再一次强制刷盘）
       │
       ▼
  SB_FREEZE_COMPLETE (4)
       │  ⑥ freeze_holders |= who
       │  ⑦ wake_up_var + lockdep 释放
       ▼
  FIFREEZE ioctl 返回给用户态

static inline void kiocb_start_write(struct kiocb *iocb)
{
    struct inode *inode = file_inode(iocb->ki_filp);

    sb_start_write(inode->i_sb);          // ← 真的持有 rw_sem[0] 读锁
    /*
     * Fool lockdep by telling it the lock got released so that it
     * doesn't complain about the held lock when we return to userspace.
     */
    __sb_writers_release(inode->i_sb, SB_FREEZE_WRITE);  // ← 只骗 lockdep
}

/* fs/aio.c:1585 aio_write() —— io_submit 时抓锁 */
if (!ret) {
    if (S_ISREG(file_inode(file)->i_mode))
        kiocb_start_write(req);           // ① 提交时抓 rw_sem[0] 读锁
    req->ki_flags |= IOCB_WRITE;
    aio_rw_done(req, call_write_iter(file, req, &iter));  // ② 异步下发，立即返回
}

/* fs/aio.c:1459 aio_complete_rw() —— IO 完成时才放锁 */
if (kiocb->ki_flags & IOCB_WRITE) {
    if (S_ISREG(inode->i_mode))
        kiocb_end_write(kiocb);           // ③ AIO 完成回调才释放读锁
}

static int ext4_sync_fs(struct super_block *sb, int wait)
{
    ...
    if (sbi->s_journal) {
        target = jbd2_get_latest_transaction(sbi->s_journal);
        if (wait && sbi->s_journal->j_flags & JBD2_BARRIER &&
            !jbd2_trans_will_send_data_barrier(sbi->s_journal, target))
            needs_barrier = true;

        if (jbd2_journal_start_commit(sbi->s_journal, &target)) {
            if (wait)
                ret = jbd2_log_wait_commit(sbi->s_journal, target);
        }
    } else if (wait && test_opt(sb, BARRIER))
        needs_barrier = true;

    if (needs_barrier) {
        err = blkdev_issue_flush(sb->s_bdev);          // ← 显式 FLUSH
    }
    return ret;
}

static int ext4_freeze(struct super_block *sb)
{
    if (journal) {
        jbd2_journal_lock_updates(journal);
        error = jbd2_journal_flush(journal, 0);        // ← 完整 checkpoint + FLUSH
        ...
    }
}

blkdev_issue_flush(bdev)
  └─ submit_bio_wait(REQ_OP_WRITE | REQ_PREFLUSH)      ← 同步阻塞等
       └─ blk_mq_submit_bio
            └─ blk_insert_flush(rq)                    block/blk-flush.c:404
                 │
                 │ 判断 blk_queue_write_cache 的 writeback 位：
                 │  - writeback=true  → 生成独立的 flush 请求，转发给驱动
                 │  - writeback=false → 直接完成，不下发（写透模式无需 flush）
                 ▼
            virtio_blk 驱动的 queue_rq
                 ▼
            virtblk_prep_rq()                          drivers/block/virtio_blk.c:263
               case REQ_OP_FLUSH:
                   type = VIRTIO_BLK_T_FLUSH;          ← 命令类型翻译
                 ▼
            virtqueue_add_sgs + virtqueue_kick         触发 eventfd 通知 Cloud Hypervisor

virtqueue kick eventfd
       ▼
BlockEpollHandler::handle_event(QUEUE_AVAIL_EVENT)      virtio-devices/src/block.rs
       ▼
process_queue()  遍历 avail ring
       ▼
Request::parse()                                        block/src/lib.rs
   parse_request_type: VIRTIO_BLK_T_FLUSH → RequestType::Flush
       ▼
Request::execute_async()                                block/src/lib.rs:508
    match request_type {
        RequestType::Flush => {
            disk_image.fsync(Some(user_data))?;         ← 后端 fsync 入口
        }
        ...
    }
       ▼
AsyncIo::fsync (trait)                                  block/src/async_io.rs:188
       │
       ├── raw_async.rs:132       io_uring opcode::Fsync            → 内核 fsync(2)
       ├── raw_async_aio.rs:115   libaio IOCB_CMD_FSYNC             → 内核 fsync(2)
       ├── raw_sync.rs:121        libc::fsync(fd)                   → 内核 fsync(2)
       ├── qcow_sync.rs:96        qcow2 元数据 flush + libc::fsync
       └── nvme_tcp.rs / vhdx / fixed_vhd 等其它后端
       ▼
Host 内核 fsync(2)：
    → 写脏页 + 提交块层 FLUSH
    → 物理盘 SCSI SYNCHRONIZE CACHE / NVMe FLUSH
       ▼
fsync 返回 → Cloud Hypervisor 收到 CQE / eventfd
       ▼
process_queue_complete()：写 used ring + queue.signal_used()
       ▼
Guest virtio_blk 收到 MSI-X 中断
       ▼
blk_mq_complete_request → bio_endio → submit_bio_wait 唤醒
       ▼
blkdev_issue_flush 返回 → ext4_sync_fs 返回
       ▼
freeze_super 继续推进 → SB_FREEZE_COMPLETE
       ▼
ioctl(FIFREEZE) 返回用户态

# 1. 确认 cache 模式：只有 write back 才会下发 FLUSH
cat /sys/block/vda/queue/write_cache
# 期望：write back

# 2. 确认挂载选项没有 nobarrier
mount | grep -E "on / |on /data" | grep -v nobarrier
# 若有 nobarrier / barrier=0 → Guest 侧根本不下 FLUSH

# 3. 触发 freeze 并追踪 flush 次数
sudo bpftrace -e '
  kprobe:blkdev_issue_flush { @[comm] = count(); }
  interval:s:10 { print(@); clear(@); }' &
sudo fsfreeze -f /mnt/data
sudo fsfreeze -u /mnt/data
# 期望能看到至少一次 blkdev_issue_flush

# 1. 追踪 Cloud Hypervisor 的 fsync 系统调用
sudo bpftrace -e '
  tracepoint:syscalls:sys_enter_fsync /comm=="cloud-hypervisor"/ {
     printf("fsync fd=%d pid=%d ts=%lu\n", args->fd, pid, nsecs);
  }
  tracepoint:syscalls:sys_exit_fsync /comm=="cloud-hypervisor"/ {
     printf("fsync return=%d ts=%lu\n", args->ret, nsecs);
  }'
# 在 Guest 内执行 fsfreeze -f 时应能看到 fsync 的入口/退出对

# 2. 观察 io_uring 提交（如果用 io_uring 后端）
sudo strace -f -e trace=io_uring_enter -p <cloud-hypervisor-pid> 2>&1 | head

# 3. 确认镜像文件的 dirty page 已回落
sudo grep -E "^(Dirty|Writeback):" /proc/meminfo   # freeze 后 Dirty 应降至底部平台