当我统计 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
) 安装在/boot
,并且/home
是 的 btrfs 子卷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_*)
请注意,文件名被截断,这是因为 util-linux 使用的loop_info64
结构在字段上有 63 个字符的限制lo_file_name
。
我能可靠地得到的是设备 ID 和备份文件的 inode 号。这就是我碰壁的地方,因为备份文件存储在 btrfs 子卷上。
答案1
我查看了 Gnu core-utils 源代码,特别是df
命令。
它会递归地降低层次结构,直到设备 ID 发生变化。 ID 发生变化的点就是挂载点。
我只是试图找到所在文件系统的挂载点~/home/me/a-dir/another-dir
。我做了:
stat . #noting device IDs
while id not changes and root not hit
do
cd ..
stat .
done
if root not hit
then
cd -
fi
(这段代码是伪 bash,所有条件和循环都是手动完成的。它只是为了证明这个概念。我将把编程和翻译留给 python 作为读者的练习。)