`FUSE_DEV_IOC_CLONE` で複製したfdを使うとファイルシステムがブロックする

[ubnt-intrepid]

実験の結果、特定の device fd から読み込んだリクエストは必ず同じfdにリプライを書き込む必要があることが分かった。

例えば、これまでのサンプルコードで用いていたように Session::next_request と Session::reply で異なるfdを用いるとファイルシステム全体がブロックしてしまう:

let conn = MountOptions::default().mount("/path/to/mountpoint")?;

while let Some(req) = session.next_request(&conn)? {
    let cloned_conn = conn.try_ioc_clone()?;
    std::thread::spawn(move || {
        ...
        session.reply(&cloned_conn, &req, data)?; // conn とは別の fd に書き込む
    });
}

このような挙動になる原因として、FUSE_DEV_IOC_CLONE によって複製された fd はそれぞれ独自の processing queue を持ち、保留中のリクエストをfd毎に管理してることが考えられる。

上の例の場合、req を conn から読み出したあと、それに対するリプライを cloned_conn に書き込んでいる。この場合 conn 側の processing queue は更新されないので、req に対応するカーネル側の処理が続行しないことになる。

上の考察を検証するため、カーネル側の実装を精査する必要がある。

[ubnt-intrepid]

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/fuse/fuse_i.h?h=v6.12.41#n534

struct fuse_dev {
	/** Fuse connection for this device */
	struct fuse_conn *fc;

	/** Processing queue */
	struct fuse_pqueue pq;

	/** list entry on fc->devices */
	struct list_head entry;
};

ここでいう pq がfd毎にアクセスされるとすれば、上の仮説は多分あってる

[ubnt-intrepid]

上の例のようにリクエストを読み込んだ後に別スレッドに移動したい場合:

let (conn, fusermount) = mount("/path/to/mountpoint", Default::default())?;
let mut conn = Connection::from(conn);

while let Some(req) = session.next_request(&conn)? {
    if req.opcode() != FUSE_WRITE {
        // メインスレッドで完結するような軽い処理
        ...
        session.reply(&conn, &req, ...)?;
    } else {
        // 別スレッドでやるような重い処理
        let cloned_conn = conn.try_ioc_clone()?;
        let conn = mem::replace(&mut conn, cloned_conn);
        std::thread::spawn(move || {
            ...
            session.reply(&conn, &req, data)?;
            Ok(())
        });
    }
}