Ich habe ein System mit 3 SSD-Geräten ( /dev/sda, /dev/sdb, /dev/sdc), die ein einzelnes logisches LVM-Volume enthalten, das sich über alle Geräte erstreckt. Ich habe eine einzelne ext4-Partition auf dem logischen Volume.
Ich denke, dass eines der SSD-Geräte ( /dev/sdb)könntekönnen gewisse Mängel aufweisen und die Leistung im Vergleich zu anderen Geräten reduziert sein.
Gibt es einen Befehl, um die Liste der von diesem Gerät gesicherten Dateien abzurufen?
Ich weiß, dass ich damit eine Liste logischer Segmente erhalten kann sudo pvdisplay -mund die Ausgabe sieht folgendermaßen aus:
--- 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
Ich weiß also, dass die logischen Erweiterungen 476932 bis 1430792 der potenziell problematische Bereich sind. Wie kann ich diesen logischen Segmentbereich tatsächlichen Dateien im Dateisystem (ext4) über dem LVM zuordnen?
Im Grunde versuche ich herauszufinden, ob das Gerät tatsächlich fehlerhaft ist oder ob das Nutzungsmuster für diese Dateien so unglücklich ist, dass ich auf ein Nutzungsmuster stoße, das für die Hardware problematisch ist und die Leistung schlechter als erwartet ist. Kein Gerät zeigt Fehler an und alle Daten sehen gut aus, aber die Leistung dieses einzelnen Geräts scheint schlechter als erwartet zu sein.
Das System ist in Gebrauch, daher würde ich dies lieber online diagnostizieren, ohne Daten zu überschreiben. Ich weiß, dass ich das möglicherweise problematische Speichergerät einfach offline nehmen und seinen Inhalt überschreiben könnte, um fioes zu vergleichen und zu sehen, ob es unter den Spezifikationen arbeitet oder nicht.
$ 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
Ich frage im Grunde, wie man eine Liste der Dateien erhält, die von einem einzelnen Speichergerät gesichert werden, wenn sich das Dateisystem über mehrere Speichergeräte erstreckt.
Oder wenn Sie Anweisungen geben können, wie man herausfindet, wo ein bestimmterDateitatsächlich gespeichert ist, wäre das auch in Ordnung. Ich würde diese Routine dann für jede Datei ausführen, um herauszufinden, welche Dateien von dem Gerät, an dem ich interessiert bin, unterstützt werden. Mir ist bewusst, dass es sein könnte, dass eine einzelne große Datei von allen Geräten unterstützt wird, wenn die Datei über einen großen Bereich lokaler Segmente fragmentiert ist. Die Antwort könnte also sein, dass eine einzelne Datei von allen Geräten unterstützt wird, aber ich habe derzeit auch keine Ahnung, wie das geht.
$ 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
Antwort1
Verwenden Sie zunächst filefragdas Dienstprogramm, um die Liste aller Dateierweiterungen zu finden:
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_offsetgibt Ihnen einen Überblick, woim Dateisystemdie Extents der Datei befinden. Beachten Sie, dass diese Zahlenin Bezug auf Dateisystemblöcke, in diesem Fall 4k.
Beispielsweise beginnt der zweite Extent dieser Datei beim Byte 11140071424 vom Dateisystemanfang.
Als nächstes untersuchen Sie Ihr LVM-Layout. Führen Sie aus sudo lvm vgcfgbackup -v, es wird ein Layout jeder VG /etc/lvm/backup/<vgname>in Textform ausgeben (und -vswitch wird Ihnen diese Namen mitteilen, wenn Sie faul sind). Es ist wichtig, einfrisch erstelltBackup-Dump, damit die darin enthaltenen „Hinweis“-Gerätenamen aktuell verwendete Geräte sind (ein alter Dump verweist auf den VG-Zustand, als Sie das letzte Mal Änderungen daran vorgenommen haben, was möglicherweise vor einigen Neustarts geschehen ist, sodass die tatsächlichen Gerätenamen seitdem geändert worden sein könnten).
Lesen Sie den Dump für die entsprechende VG. Er ist recht ausführlich, aber leicht zu verstehen. Zunächst werden verschiedene allgemeine Informationen zur VG aufgelistet, von denen die PE-Größe wichtig ist. Dann werden PVs aufgelistet. Notieren Sie sich, an welchem PV Sie interessiert sind.
Und weiter unten werden alle LVs als Segmentsatz aufgelistet. Für jedes Segment wird angegeben, wo es zugeordnet ist, PV und Standort in Bezug auf LVM-Ausdehnungen.
Sehen Sie sich das Beispiel an (ich habe nicht zugehörige Teile entfernt):
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
]
}
}
}
}
Dies ist das LV, in dem sich das obige Dateisystem befindet. Wir sehen, dass es sich vollständig auf pv0 befindet und der obige Umfang der Datei bei Byte 11140071424 + 15744 * 4MiB = 77175193600 des Geräts beginnt sda4. Wenn sich das Dateisystem über mehrere Segmente erstrecken würde, müsste ich deren Größe (in Bytes) von der Byteposition des Dateiumfangs (11140071424) abziehen, bis ich in der Mitte eines bestimmten Segments lande.
Antwort2
DukönnteSie können sich mithilfe von einen allgemeinen Überblick darüber verschaffen, wo sich die Datei befindet debugfs, aber das hängt stark davon ab, wie Ihre LVs erstellt wurden. Wenn sie den Striped-Typ verwenden, werden die Daten nicht sequenziell auf die Laufwerke geschrieben (zuerst Laufwerk 1, dann Laufwerk 2 usw.), sodass die Extents aufgeteilt werden.
Denken Sie daran, dass die Dateisystemebene (ext4) das zugrunde liegende Blockgerät nicht kennt und sich auch nicht darum kümmert. Sie betrachtet es lediglich als einen großen Speicherplatz, den sie zum Erstellen von Dateien verwenden kann. Ebenso kennt und kümmert sich das LV nicht um das darüber liegende Dateisystem, da seine Aufgabe lediglich darin besteht, seine eigenen zugrunde liegenden physischen Geräte zu verwalten.
Aus diesem Grund ist das, was das LV als Extent 476932 bis 1430792 bezeichnet, nicht unbedingt das, was das Dateisystem als Extent bezeichnet. Da es sich jedoch um einen so großen Bereich von Extents handelt, können Sie möglicherweise zumindest eine ungefähre Schätzung abgeben.
Ein Beispiel für die Verwendung debugfsvon/dev/xvda2, das ist meine Root-Partition (/):
# 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
Sie können sehen, dass sich diese Datei an den Speicherorten 4145465-4145467 befindet. Wenn das zugrunde liegende LV als lineares LV erstellt wurde, ist es möglich, dass diese Speicherorte gleich oder sehr ähnlich sind.