모든 장치에 걸쳐 있는 단일 LVM 논리 볼륨을 포함하는 3개의 SSD 장치( /dev/sda, /dev/sdb, ) 가 있는 시스템이 있습니다 . /dev/sdc논리 볼륨에 단일 ext4 파티션이 있습니다.
SSD 장치 중 하나인 것 같아요( /dev/sdb)~할 것 같다다른 장치에 비해 다소 결함이 있고 성능이 저하되었습니다.
해당 장치에서 지원하는 파일 목록을 가져오는 명령이 있습니까?
나는 논리 세그먼트 목록을 얻을 수 sudo pvdisplay -m있으며 출력은 다음과 같다는 것을 알고 있습니다.
--- Physical volume ---
PV Name /dev/sda
VG Name storage
PV Size <1,82 TiB / not usable <1,09 MiB
Allocatable yes (but full)
PE Size 4,00 MiB
Total PE 476932
Free PE 0
Allocated PE 476932
PV UUID h3x3O1-1KWj-3pY6-kZ24-MVV4-54UE-ltEdfA
--- Physical Segments ---
Physical extent 0 to 476931:
Logical volume /dev/storage/vm
Logical extents 0 to 476931
--- Physical volume ---
PV Name /dev/sdb
VG Name storage
PV Size <3,64 TiB / not usable <3,84 MiB
Allocatable yes (but full)
PE Size 4,00 MiB
Total PE 953861
Free PE 0
Allocated PE 953861
PV UUID MsNlhh-W2It-CbX4-IxJn-lXJN-hlcd-EpBh9Q
--- Physical Segments ---
Physical extent 0 to 953860:
Logical volume /dev/storage/vm
Logical extents 476932 to 1430792
--- Physical volume ---
PV Name /dev/sdc
VG Name storage
PV Size <3,64 TiB / not usable <3,84 MiB
Allocatable yes (but full)
PE Size 4,00 MiB
Total PE 953861
Free PE 0
Allocated PE 953861
PV UUID sklK6w-XZd6-DqIp-ZT1g-O9rj-1ufw-UaC0z4
--- Physical Segments ---
Physical extent 0 to 953860:
Logical volume /dev/storage/vm
Logical extents 1430793 to 2384653
따라서 논리적 확장 476932에서 1430792가 잠재적으로 문제가 있는 영역이라는 것을 알고 있습니다. 이 논리 세그먼트 범위를 LVM 상단의 파일 시스템(ext4)에 있는 실제 파일에 어떻게 매핑합니까?
기본적으로 장치에 실제로 결함이 있는지 또는 이러한 파일의 사용 패턴이 하드웨어에 문제가 있는 사용 패턴에 도달하고 성능이 예상보다 나빠질 만큼 운이 좋지 않은지 알아내려고 노력하고 있습니다. 어떤 장치도 오류를 표시하지 않고 모든 데이터가 좋아 보이지만 이 단일 장치의 성능은 예상보다 좋지 않은 것 같습니다.
시스템이 사용 중이므로 데이터를 덮어쓰지 않고 온라인으로 진단하고 싶습니다. 잠재적으로 문제가 있는 저장 장치를 오프라인으로 전환하고 해당 내용을 덮어쓸 수 있다면 fio이를 벤치마킹하여 사양 이하로 작동하는지 확인할 수 있다는 것을 알고 있습니다 .
$ lsblk -s
...
storage-vm 253:0 0 9,1T 0 lvm /mnt/storage
├─sda 8:0 0 1,8T 0 disk
├─sdb 8:16 0 3,7T 0 disk
└─sdc 8:32 0 3,7T 0 disk
기본적으로 파일 시스템이 여러 저장 장치에 걸쳐 있을 때 단일 저장 장치에서 백업되는 파일 목록을 얻는 방법을 묻고 있습니다.
또는 주어진 위치를 파악하는 방법에 대한 지침을 제공할 수 있는 경우파일실제로 저장되어 있으므로 그것도 괜찮습니다. 그런 다음 모든 파일에 대해 해당 루틴을 실행하여 관심 있는 장치에서 어떤 파일이 백업되는지 파악합니다. 파일이 여러 개로 조각화되면 하나의 큰 파일이 모든 장치에서 백업될 수 있다는 것을 알고 있습니다. 광범위한 로컬 세그먼트가 있으므로 단일 파일이 모든 장치에서 지원된다는 대답이 나올 수 있지만 현재는 이 작업을 수행하는 방법도 모릅니다.
$ sudo vgdisplay
--- Volume group ---
VG Name storage
System ID
Format lvm2
Metadata Areas 3
Metadata Sequence No 6
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 3
Act PV 3
VG Size <9,10 TiB
PE Size 4,00 MiB
Total PE 2384654
Alloc PE / Size 2384654 / <9,10 TiB
Free PE / Size 0 / 0
VG UUID MOrTMY-5Dly-48uQ-9Fa8-JNvf-tont-9in7ol
$ sudo lvdisplay
--- Logical volume ---
LV Path /dev/storage/vm
LV Name vm
VG Name storage
LV UUID RDkaLH-mh6C-cXxT-6ojc-DxkB-o4jD-3CMHdl
LV Write Access read/write
LV Creation host, time staging, 2021-01-21 09:57:06 +0200
LV Status available
# open 1
LV Size <9,10 TiB
Current LE 2384654
Segments 3
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
답변1
우선 filefrag유틸리티를 사용하여 모든 파일 범위 목록을 찾습니다.
merlin@uc-s4m75657:~$ sudo filefrag /mnt/spool/merlin/VMs/slax-64bit-11.4.0-merlin.iso -e
Filesystem type is: ef53
File size of /mnt/spool/merlin/VMs/slax-64bit-11.4.0-merlin.iso is 322979840 (78853 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 8191: 2703360.. 2711551: 8192:
1: 8192.. 14335: 2719744.. 2725887: 6144: 2711552:
2: 14336.. 57343: 2732032.. 2775039: 43008: 2725888:
3: 57344.. 65535: 2783232.. 2791423: 8192: 2775040:
4: 65536.. 71679: 2797568.. 2803711: 6144: 2791424:
5: 71680.. 78852: 2811904.. 2819076: 7173: 2803712: last,eof
/mnt/spool/merlin/VMs/slax-64bit-11.4.0-merlin.iso: 6 extents found
physical_offset개요를 알려드릴 것입니다.파일 시스템에서파일의 범위를 찾습니다. 이 숫자는 다음과 같습니다.파일 시스템 블록 측면에서, 이 경우에는 4k입니다.
예를 들어, 이 파일의 두 번째 확장 영역은 파일 시스템 시작 시 바이트 11140071424에서 시작됩니다.
다음으로 LVM 레이아웃을 살펴보세요. Run 을 실행하면 sudo lvm vgcfgbackup -v각 VG의 레이아웃이 /etc/lvm/backup/<vgname>텍스트 형식으로 덤프됩니다( -v게으른 경우 스위치를 사용하여 이러한 이름을 알려줍니다). 다음을 사용하는 것이 중요합니다.갓 생성된백업 덤프 - 그 안에 있는 "힌트" 장치 이름이 현재 실제로 사용되는 장치입니다(오래된 덤프는 마지막으로 변경했을 때의 VG 상태를 참조합니다. 이는 몇 번의 재부팅 전에 발생했을 수 있으므로 실제 장치 이름은 그 이후로 변경되었을 수 있습니다.)
해당 VG에 대한 덤프를 읽으십시오. 꽤 장황하지만 이해하기 쉽습니다. 먼저 VG에 대한 다양한 공통 정보를 나열하는데, 그 중 PE 크기가 중요합니다. 그런 다음 PV를 나열하고 관심 있는 PV를 기록해 둡니다.
아래에는 모든 LV가 세그먼트 세트로 나열됩니다. 각 세그먼트에 대해 LVM 범위 측면에서 매핑된 위치, PV 및 위치를 나타냅니다.
예제를 보세요(관련 없는 부분은 제거했습니다):
system {
#...
extent_size = 8192 # 4 Megabytes
#...
physical_volumes {
pv0 {
#...
device = "/dev/sda4" # Hint only
#...
pe_start = 2048
pe_count = 57105 # 223,066 Gigabytes
}
}
logical_volumes {
#...
spool {
#...
segment_count = 1
segment1 {
start_extent = 0
extent_count = 41361 # 161,566 Gigabytes
#...
stripes = [
"pv0", 15744
]
}
}
}
}
위의 파일 시스템이 위치한 LV입니다. 우리는 그것이 pv0에 완전히 위치하고 위의 파일 범위가 장치의 바이트 11140071424 + 15744 * 4MiB = 77175193600에서 시작한다는 것을 알 수 있습니다 sda4. 파일 시스템이 여러 세그먼트에 걸쳐 있는 경우 특정 세그먼트의 중간에 도달할 때까지 파일 범위 바이트 위치(11140071424)에서 해당 크기(바이트)를 빼야 합니다.
답변2
너~할 것 같다를 사용하여 파일의 위치에 대한 일반적인 아이디어를 얻을 수 있지만 debugfsLV가 생성된 방법에 따라 크게 달라집니다. 스트라이프 유형을 사용하는 경우 데이터가 드라이브(첫 번째 드라이브1, 다음 드라이브 2 등)에 순차적으로 기록되지 않으므로 익스텐트가 나누어집니다.
파일 시스템 계층(ext4)은 기본 블록 장치를 모르거나 신경 쓰지 않는다는 점을 기억하십시오. 단지 파일을 생성하는 데 사용할 수 있는 큰 공간으로 간주됩니다. 마찬가지로 LV는 자신의 기본 물리적 장치를 관리하는 역할만 하기 때문에 오버레이 파일 시스템에 대해 모르거나 신경 쓰지 않습니다.
이 때문에 LV가 범위 476932 ~ 1430792를 호출하는 것이 반드시 파일 시스템이 해당 범위를 호출하는 것은 아닙니다. 하지만 그 범위가 워낙 넓기 때문에 최소한 야구장까지는 들어갈 수도 있을 것입니다.
debugfson을 사용하는 예/dev/xvda2, 이는 내 루트(/) 파티션입니다.
# debugfs /dev/xvda2
debugfs 1.46.5 (30-Dec-2021)
debugfs: ls /root
262146 (12) . 2 (12) .. 268932 (12) .ssh
268409 (16) .bashrc 268410 (16) .profile 276186 (16) .cache
268256 (16) .ansible 268318 (24) .vim
268408 (24) .bash_completion
267590 (16) .vimrc 262167 (24) .bash_history
debugfs: stat /root/.bashrc
Inode: 268409 Type: regular Mode: 0644 Flags: 0x80000
Generation: 4101506038 Version: 0x00000000:00000001
User: 0 Group: 0 Project: 0 Size: 10137
File ACL: 0
Links: 1 Blockcount: 24
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x64c7f06b:37648614 -- Mon Jul 31 12:33:31 2023
atime: 0x660f7b2c:32146cc8 -- Thu Apr 4 23:16:44 2024
mtime: 0x64c7ef9d:00000000 -- Mon Jul 31 12:30:05 2023
crtime: 0x641493b2:49f692b4 -- Fri Mar 17 11:22:10 2023
Size of extra inode fields: 32
Inode checksum: 0x8cc75e77
EXTENTS:
(0-2):4145465-4145467
이 파일은 익스텐트 4145465-4145467에 있음을 알 수 있습니다. 기본 LV가 선형 LV로 생성된 경우 이러한 범위는 동일하거나 매우 유사할 수 있습니다.