LVM hängt nach Größenänderung nicht mehr zusammen

[Spindoctor]

Hallo!

Ich hoffe, das gehört in das Hardware-Forum...

Als ich Debian installiert habe, hab ich zum ersten Mal LVM verwendet. Ich hab allerdings für die Root-Partition etwas zu wenig Speicher reserviert (nämlich nur 10 GB). Vor und nach Updates hat das manchmal zu leichten Schwierigkeiten geführt.

Nun habe ich die Root-Partition auf 25 GB vergrößert. Bei einem finalen Check bin ich dann auf folgendes Bild gestoßen

Die Root-Partition hängt also nicht mehr zusammen sondern wird von der Home-Partition unterbrochen.

Wie kann ich die Root-Partition wieder schön zusammenhängend machen?

Oder ist das (a) grundsätzlich egal bzw. (b) egal, weil es eine SSD ist?

Danke schonmal für die Hilfe!

[dirk11]

Ich hab allerdings für die Root-Partition etwas zu wenig Speicher reserviert (nämlich nur 10 GB). Vor und nach Updates hat das manchmal zu leichten Schwierigkeiten geführt.

Was? Hast Du auch "empfohlene Pakete" installiert, oder wie kommt sowas zustande? Ich war immer der Meinung, daß man, wenn man nicht gerade *jeden* Desktop-Manager installiert, man immer noch locker mit 5GB auskommt. Tue ich jedenfalls.

[heisenberg]

Das Bild laesst noch Fragen offen. Zeig' Doch nochmal die Ausgaben folgender Kommandos, die Du als root ausführst:

Code: Alles auswählen

lsblk
vgdisplay -v

Falls Du nicht weisst wie das geht, schau mal hier: Ein Terminal öffnen.

[heisenberg]

Was? Hast Du auch "empfohlene Pakete" installiert, oder wie kommt sowas zustande? Ich war immer der Meinung, daß man, wenn man nicht gerade *jeden* Desktop-Manager installiert, man immer noch locker mit 5GB auskommt. Tue ich jedenfalls.

Da kann man sich durchaus drüber streiten(oder man kann es lassen), siehe hier:

http://www.linuxforen.de/forums/showthr ... rzelordner

[rendegast]

Auf einer HDD wäre /root wirklich nicht zusammenhängend,
die logische Darstellung entspräche dem physischen Zustand.

Und auf einer SSD macht diese Betrachtung keinen Sinn,
da die beschriebenen Blöcke lustig durch das device wandern,
die logische Darstellung das aber nicht darstellen kann.
Ein Versuch das logisch wieder "schön" zu machen,
würde nur Schreibvorgänge auf der SSD erzeugen,
mit einem noch "fragmentierterem" Ergebnis.
Auch ein Defragmentieren (Dateien wie lvm) über Imagen auf eine HDD hilft nicht,
denn SSD merken sich die Schreibvorgänge der Blöcke und würden beim Zurückkopieren des defragmentierten Image weniger beschriebene Blöcke benutzen, also nicht linear schreiben.

[Bequimao]

Hallo!

Ich hoffe, das gehört in das Hardware-Forum...

Als ich Debian installiert habe, hab ich zum ersten Mal LVM verwendet. Ich hab allerdings für die Root-Partition etwas zu wenig Speicher reserviert (nämlich nur 10 GB). Vor und nach Updates hat das manchmal zu leichten Schwierigkeiten geführt.
...
Wie kann ich die Root-Partition wieder schön zusammenhängend machen?

Oder ist das (a) grundsätzlich egal bzw. (b) egal, weil es eine SSD ist?

Danke schonmal für die Hilfe!

Zur ursprünglichen Frage: Es ist grundsätzlich egal. Wenn es bei SSD doch etwas ausmacht, dann ist es ein Bug.

Viele Grüße
Bequimão

[Spindoctor]

Vielen Dank für die vielen Beiträge!

@ heisenberg
Das mit dem Terminal bekomm ich hin

Code: Alles auswählen

# lsblk
NAME                    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                       8:0    0 238,5G  0 disk  
├─sda1                    8:1    0    94M  0 part  /boot/efi
└─sda2                    8:2    0 238,4G  0 part  
  ├─SSD-ROOT            253:0    0  24,3G  0 lvm   /
  └─SSD-HOME            253:1    0 214,1G  0 lvm   /home
sdb                       8:16   0   1,8T  0 disk  
└─sdb1                    8:17   0   1,8T  0 part  
  └─md0                   9:0    0   1,8T  0 raid1 
    └─HDD-HOME_BIG_DATA 253:2    0   1,8T  0 lvm   /mnt/home-big-data
sdc                       8:32   0   1,8T  0 disk  
└─sdc1                    8:33   0   1,8T  0 part  
  └─md0                   9:0    0   1,8T  0 raid1 
    └─HDD-HOME_BIG_DATA 253:2    0   1,8T  0 lvm   /mnt/home-big-data
sde                       8:64   0   1,8T  0 disk  
└─sde1                    8:65   0   1,8T  0 part  /media/marcel/exthd
sr0                      11:0    1  1024M  0 rom   

# vgdisplay -v
    No PV label found on /dev/SSD/ROOT.
    No PV label found on /dev/sda1.
    No PV label found on /dev/SSD/HOME.
    No PV label found on /dev/HDD/HOME_BIG_DATA.
    No PV label found on /dev/sde1.
  --- Volume group ---
  VG Name               SSD
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  6
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               238,38 GiB
  PE Size               4,00 MiB
  Total PE              61025
  Alloc PE / Size       61025 / 238,38 GiB
  Free  PE / Size       0 / 0   
  VG UUID               ZJJwU1-Gpbw-KsQI-ot1j-Uo55-b93Z-8qdF9p
   
  --- Logical volume ---
  LV Path                /dev/SSD/ROOT
  LV Name                ROOT
  VG Name                SSD
  LV UUID                0oWRv5-kpLd-KOYz-OVDL-iS9I-Luf0-fRXkrX
  LV Write Access        read/write
  LV Creation host, time medienschwammerl-marcel, 2015-05-31 13:30:00 +0200
  LV Status              available
  # open                 1
  LV Size                24,31 GiB
  Current LE             6224
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0
   
  --- Logical volume ---
  LV Path                /dev/SSD/HOME
  LV Name                HOME
  VG Name                SSD
  LV UUID                aOZZh1-Anec-MKIx-4tQk-282o-iFWP-ARh0p1
  LV Write Access        read/write
  LV Creation host, time medienschwammerl-marcel, 2015-05-31 13:30:16 +0200
  LV Status              available
  # open                 1
  LV Size                214,07 GiB
  Current LE             54801
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1
   
  --- Physical volumes ---
  PV Name               /dev/sda2     
  PV UUID               iqHvwY-Ibcf-bUFl-8daC-V6fm-oHo3-oy1iNY
  PV Status             allocatable
  Total PE / Free PE    61025 / 0
   
  --- Volume group ---
  VG Name               HDD
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1,82 TiB
  PE Size               4,00 MiB
  Total PE              476899
  Alloc PE / Size       476899 / 1,82 TiB
  Free  PE / Size       0 / 0   
  VG UUID               eANrKR-zBk9-HiEr-9Q2y-sM6O-8v20-do93Nr
   
  --- Logical volume ---
  LV Path                /dev/HDD/HOME_BIG_DATA
  LV Name                HOME_BIG_DATA
  VG Name                HDD
  LV UUID                MePyC3-wh9E-oAKh-3K3L-NxkC-vwmp-UYK6Z8
  LV Write Access        read/write
  LV Creation host, time medienschwammerl-marcel, 2015-05-31 14:28:38 +0200
  LV Status              available
  # open                 1
  LV Size                1,82 TiB
  Current LE             476899
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2
   
  --- Physical volumes ---
  PV Name               /dev/md0     
  PV UUID               nRdCFB-HfaL-2dIg-Gu9A-yZPp-c6TP-tduRp3
  PV Status             allocatable
  Total PE / Free PE    476899 / 0

@dirk11
Ich dachte auch, dass die 10 GB reichen. Und ich hab auch nicht extrem viel installiert - also desktopmäßig nur Gnome 3. Vielleicht hast Du/vielleicht habt ihr ja einen Tipp für mich, wie ich Platz freimachen kann?


@ Bequimao und andere
Jedenfalls mal danke - auf einer SSD macht es also nichts.

Interessehalber: Gibt es für eine Festplatte einen einfachen Weg, die Partition zusammenhängend zu machen?

[dirk11]

Mal die essentiellen Angaben auf meinem Desktop:

Code: Alles auswählen

/# du -shx ./* | sort -h
16K	./tmp
684K	./run
8,5M	./sbin
12M	./bin
13M	./etc
52M	./root
55M	./boot
307M	./var
385M	./lib
2,9G	./usr

/# cd usr
/usr# du -shx ./* | sort -h
100K	./games
608K	./include
16M	./sbin
72M	./src
172M	./bin
257M	./local
915M	./share
1,5G	./lib

Environment ist hier Xfce.
Du hast wohl wirklich alles installiert, was nicht bei drei auf die Bäume kam - oder frißt Gnome bzw. KDE mittlerweile so viel Platz?...

Mal zum Vergleich ein Rechner ohne grafische Oberfläche:

Code: Alles auswählen

/# du -shx ./*  | sort -h
4,0K	./srv
164K	./root
708K	./run
8,7M	./sbin
9,7M	./etc
12M	./bin
32M	./boot
203M	./lib
544M	./var
1,2G	./usr

/# cd usr
/usr# du -shx ./* | sort -h
88K	./games
172K	./include
20M	./sbin
110M	./bin
241M	./local
314M	./lib
525M	./share

[heisenberg]

Ok. Ich habe nun also gesehen, dass Dein geteiltes /-FS wirklich auch ein LVM-LV ist .

Dass das aufgeteilt ist, ist überhaupt kein Problem, da LVM die Zuordnung des Speichers zwischen den Logischen Volumes(z. B. ROOT hier) und den physikalischen Volumes(hier /dev/sda2) übernimmt.

Grundsätzlich _sehe_ ich mit Deiner Grafik auch zum ersten Mal eine tatsächliche Aufteilung der Logischen Blöcke(oder LE = Logical Extents) auf einem Physikalischen Volume(PV).

Ich würde das so lassen, wie es ist, da ich keine Nachteile sehe.

Gibt es irgendwelche speziellen Gründe, warum Du die Datenbereiche wieder zusammenfügen möchtest, ausser dass es nicht so hübsch aussieht?

[whisper]

Thema root Filesystem:
Bei meinem T500, zugegebenermaßen viel instaliert:

Code: Alles auswählen

Dateisystem                Größe Benutzt Verf. Verw% Eingehängt auf
/dev/dm-0                    25G     21G  2,8G   89% /

Soviel zum Thema 25Gig bekommt man nicht voll und ist viiiel zu groß

[dirk11]

Ich frage mich nur immer, ob das alles auch wirklich genutzt wird und da nicht einfach Hunderte Pakete mit überflüssigem shice installiert sind.

[Spindoctor]

@ heisenberg
Gell, hässlich ist es schon Aber ich werde es jetzt so lassen. Auf einer SSD kann ich ja mehr kaputt machen als reparieren, wenn ich hier was tue.

Nur interessehalber, im Sinne von "Forumsbeiträge als Wissensdatenbank für zukünftige Recherchen", würde mich interessieren, ob es einen leichten Weg gibt das zu bereinigen. Weil auf einer Festplatte wärs wahrscheinlich nicht so problemlos, oder?

@ dirk
Ja, gute Frage, ob das wirklich genutzt wird. Bei mir sind die großen Brocken jdfs. /usr/lib/x86_64-linux-gnu (darin einfach kleine aber sehr viele Ordner - der größte webkit2gtk-4.0 mit 36 MB) und /usr/share (darin hauptsächlich locale/, games/, doc/ und help/).

Vielleicht könnte man ein paar locales löschen (wobei, wie?). Aber sonst weiß ich auch nicht was weg sollte.

Danke nochmals!

[dirk11]

Vielleicht könnte man ein paar locales löschen (wobei, wie?). Aber sonst weiß ich auch nicht was weg sollte.

Was soll das bringen? Problem ist in meinen Augen, daß z.B. a) Metapakete unglaublich viel Kram installieren, den man in den allermeisten Fällen niemals braucht und das b) z.B. bei aptitude die Standard-Einstellung "Empfohlene Pakete installieren" ist, was auf's selbe hinausläuft. Im Normalfall reicht es aus, wenn man sich auf die Abhängigkeiten verläßt, die werden immer korrekt aufgelöst.

Unterm Strich ist das dann ein mördermäßiges Datenvolumen (z.B. bei updates oder gar upgrades), welches man da durch die Welt schaufelt, was man aber niemals im Leben nutzt. Und es ist halt auch eine erhebliche Fehlerquelle.

[Spindoctor]

die Locales löschen würde in meinem Fall ungefähr 700 MB bringen. Habs grad mit dem Paket localepurge probiert, aber das hat die locales in /usr/share/locale leider nicht gelöscht...

Das mit den Abhängigkeiten und den empfohlenen Paketen kann ich leider nicht beurteilen. Ich verwende jdfs. seit einigen Monaten hauptsächlich apt (nicht apt-get oder aptitude).

[dirk11]

Ich verwende jdfs. seit einigen Monaten hauptsächlich apt (nicht apt-get oder aptitude).

Warum? aptitude ist bewährt & stabil, und man kann es als Befehl oder als CLI verwenden.

[Spindoctor]

apt ist irgendwie hübscher. Hab auch mal gelesen, dass apt ab sofort empfohlen wird, gegenüber apt-get und aptitude. Aber momentan finde ich nur diesen Link:
https://www.debian.org/doc/manuals/debi ... et.en.html

Spricht aus Deiner Sicht was gegen apt?

[dirk11]

apt ist irgendwie hübscher.
[...]
Spricht aus Deiner Sicht was gegen apt?

Nein, aber es spricht aus meiner Sicht eben auch nicht dafür. Bei aptitude habe ich meine gewohnte CLI *oder* kann es als Kommandozeilentool verwenden, apt ist rein kommandozeilenbasiert. Und ich habe mit aptitude, was Auflösung von Konflikten angeht, nur gute Erfahrungen in den letzten Jahren gemacht, man kann gut vor Ausführung sehen, was passieren wird - es gibt schlicht keinen Grund, aptitude nicht zu verwenden.

[rendegast]

Ich empfehle nicht niemals nie localepurge zu verwenden.

[dirk11]

Why not?

[rendegast]

Ich empfehle nicht niemals nie localepurge zu verwenden.

Why not?

Aus dem Link

Dieses Werkzeug ist sehr einfach programmiert und NICHT im Debian- Paketsystem integriert. Daher ist es nichts für schwache Nerven. Dieses Programm greift in die Debian-Paketverwaltung ein und ruft ungewöhnliches, aber ansonsten harmloses Verhalten, bei mit apt/dpkg verwandten Programmen wie dpkg- repack, reportbug, usw. hervor. Die Verantwortung für die Anwendung des Skripts und daraus resultierende mögliche Schäden an Ihrem System verbleibt daher in der Hand des Systemadministrators (bei Ihnen).

Bitte melden Sie keine Fehler, die nach der Anwendung von localepurge und einem daraus resultierenden defekten System auftreten. Wenn Sie nicht wissen, was dies alles bedeutet und Sie ein daraus resultierendes defektes System nicht selbstständig reparieren können, installieren Sie bitte dieses Paket nicht.

und eigene Erfahrung,
aktive in Anwendung und passiv als Ratgeber im Folgefehlerfall.


Ein Integritätstest

Code: Alles auswählen

cd /
md5sum -c /var/lib/dpkg/info/*.md5sums
(EDIT)

kann bei einem validen System schon genügend Meldungen machen.

Code: Alles auswählen

$ cat /var/lib/dpkg/info/*.md5sums | grep locale/ | wc -l
7494

Lagen die Fehler dann an localepurge oder doch was anderem?

Code: Alles auswählen

$ du -smc locale/
267     locale/
267     insgesamt

Die in meinem Fall 200MB sind mir das dann doch nicht wert.
Da lösche ich lieber irgendein altes kali-iso.
Auch verglichen mit zBsp.

Code: Alles auswählen

$ du -smc /lib/modules/*
221     /lib/modules/3.16.0-4-amd64
229     /lib/modules/4.3.0-0.bpo.1-amd64

[dirk11]

Interessant. Verbessere doch bitte den ersten und den vorletzten Befehl. Beim ersten fehlt ein / und beim vorletzten weiß ich ad hoc nicht, was Du willst.

Zum Thema: die Fehler treten - jedenfalls soweit ich das blitzlichtähnlich erfassen kann, so schnell wie das durchscrollt - doch nur bei den locale auf, also in /usr/share/locale/*. Wen interessiert's? Ich habe beim Paketmanagement damit keine Probleme, selbst upgrades von oldstable auf stable funktionieren damit tadellos. Für mich ist die Besorgnis damit nicht so ganz nachvollziehbar.