确定给定文件的LVM范围编号


9

我目前正在从事与工作无关的家庭作业。我有一个坐在逻辑卷上的ext4文件系统。我正在测试不同的性能调整策略,这个想法出现在我身上。由于pvmove可以移动单个范围和范围的范围,因此有一种方法可以绘制出哪些物理范围来保存特定文件(理论上它可以为数据库备份文件或大型的常用文件共享)并将它们移至特定范围存储设备(例如,我在同一LVM卷组中有一个常规HDD和一个SSD驱动器)?

我曾想过使用“ filefrag”,但后来我发现对于范围号是否必须按顺序使用并不是100%的了解(因此知道ext4中有多少个扇区可以看到一个文件并不一定会让我可以找出文件实际位于哪个扩展区编号/卷上。

有任何想法吗?

Answers:


13

两个主要成分是hdparm --fibmap file,它告诉您文件在LV中的物理位置,并lvs -o +seg_pe_ranges,vg_extent_size告诉您设备上LV的物理位置。

其余的是数学。

因此,例如:

# hdparm --fibmap linux-3.8.tar.bz2 

linux-3.8.tar.bz2:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0     288776     298511       9736
     4984832     298520     298623        104
     5038080     298640     298695         56
     5066752     298736     298799         64
     5099520     298824     298895         72
     [...]

我不知道为什么这么分散-用wget下载。可能是一个很好的例子,因为如您所见,如果不编写脚本,至少在碎片文件中,您会头疼。我将仅介绍第一部分288776-298511(9736个扇区)。该计数是错误的,因为它不是512字节的扇区,但是无论如何。

首先检查此数据是否正确:

# dd if=linux-3.8.tar.bz2 bs=512 skip=0 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0506548 s, 98.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

# dd if=/dev/lvm/src bs=512 skip=288776 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.123292 s, 40.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

Wheeee。完全相同,因此我们在正确的位置阅读了LV-src。现在,源LV在哪里?

# lvs -o +seg_pe_ranges,vg_extent_size
  LV          VG   Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert PE Ranges             Ext   

[...]
 src         lvm  -wi-ao---   4.00g                                            /dev/dm-1:5920-6047   32.00m
[...]

现在很无聊,这个LV还没有零散。这里没有头疼。无论如何。

它说src在/ dev / dm-1上,开始于PE 5920,结束于PE6047。PE大小为32 MiB。

因此,让我们看看是否可以直接从/ dev / dm-1读取相同的内容。在数学上,这有点荒谬,因为我们之前使用了512字节的块大小...:-/但是我很懒,所以我只计算MiB,然后除以512!哈!:-D

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0884709 s, 56.3 MB/s
3858a4cd75b1cf6f52ae2d403b94a685  -

嘘 这不是我们想要的。什么地方出了错?啊! 我们忘记在PV的开头添加LVM占用的偏移量,用于存储LVM元数据和废话。通常这是MiB对齐的,因此只需添加另一个MiB:

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776 + 1024*1024/512)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0107592 s, 463 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

你有它。


3
有一天,他们将为您建造雕像。
Bratchley

不过,有一件事,是我的hdparm调用为何出现段错误的原因吗?
Bratchley

实际上,罢工似乎需要改进google-fu。这是与SSD和LVM有关的RHEL新错误。我将其表示该文件已经在SSD上。Ha
Bratchley

在解决此问题之前,还有其他实用程序可以确定文件在LV中的位置吗?
Bratchley

您已经提到过- filefrag。否则,如果有其他工具执行fibmap或fiemap,则使用google。
frostschutz 2013年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.