btrfsサブボリュームのファイル数を数えると、主要なデバイス番号がで表示されます0。デバイスがbtrfsサブボリュームであることを事前に知らずにデバイスのマウントポイントを見つけるための安定した方法はありますか？

たとえば、私はPythonで次のようなことをしたいと思います。

>>> st = os.stat('a file')
>>> os.major(st.st_dev)
0
>>> os.minor(st.st_dev)
38
>>> os.path.exists('/sys/dev/block/0:38')
False
>>> magic_method_that_gets_mount_point(0, 38)
'/home'
>>> magic_method_that_gets_mount_point(8, 1)
'/boot'

（私の場合はsda1（/sys/dev/block/8:1）がにマウントされており、/bootbtrfs/homeサブボリュームですsda2。）

編集する

ファイルパスを知らなくてもこれを行うことができるはずです。上記の例を使用しましたが、os.stat情報は実際にはioctl次を返すループデバイスを呼び出して取得されます。

struct loop_info64 {
    uint64_t    lo_device;
    uint64_t    lo_inode;
    uint64_t    lo_rdevice;
    uint64_t    lo_offset;
    uint64_t    lo_sizelimit;
    uint32_t    lo_number;
    uint32_t    lo_encrypt_type;
    uint32_t    lo_encrypt_key_size;
    uint32_t    lo_flags;
    uint8_t     lo_file_name[64];
    uint8_t     lo_crypt_name[64];
    uint8_t     lo_encrypt_key[32];
    uint64_t    lo_init[2];
};

このフィールドはありますが、lo_file_name最大長は63文字なので、安定して開くことはできません。私もそれを知っていますが、/sys/block/loopX/loop/backing_fileこれはLinux> = 2.6.37でのみ利用可能で、私のコードはCentOS 6（2.6.32）で実行する必要があります。

編集＃2

私の最終目標は、ループデバイスのサポートファイルを確実に見つけることです。 util-linuxも2.6.37未満のカーネルではこれを行いません。

> dd if=/dev/urandom bs=4096 count=256 of=/root/a_really_really_really_really_really_really_really_long_file_name.img
256+0 records in
256+0 records out
1048576 bytes (1.0 MB) copied, 0.137397 s, 7.6 MB/s
> LD=`losetup -f --show /root/a_really_really_really_really_really_really_really_long_file_name.img`
> losetup $LD
/dev/loop1: [fd00]:922372 (/root/a_really_really_really_really_really_really_really_long_*)

loop_info64util-linuxで使用される構造には、フィールドに63文字の制限があるため、ファイル名が切り捨てられますlo_file_name。

私が確実に取得できるのは、デバイスIDとバックアップファイルのinode番号です。バックアップファイルがbtrfsサブボリュームに保存されるため、これは私が壁にぶつかった部分です。