Gelöst Festplattenwechsel Dateisystem

egweber1 · 5 Dez. 2022

Hallo, hab meine alte HDD mit 500 GB gegen eine SSD mit 1TB ausgetauscht. Nach dem Tausch funktionierte der Bootlader nur noch im abgesicherten Modus.
Erst als ich die fstab geändert habe, konnte ich mich als normaler Benutzer wieder anmelden. Ist das normal?
Die Platte soll hauptsächlich Videos beinhalten. Mit welchem Dateisystem formatiere ich die Platte am besten?
Auf meiner NVME für Tumbleweed habe ich btrfs. Bitte um Vorschläge.

marce · 5 Dez. 2022

ob das normal ist hängt davon ab, was in der fstab drin stand. Bei festen IDs ist das Verhalten nicht unüblich.

Als Dateisystem würde ich klassisches ext4 oder xfs vorschlagen - Features wie Snapshots braucht man auf einer Datenpart. für Medien eher weniger.

Christina · 5 Dez. 2022

egweber1 schrieb:
Hallo, hab meine alte HDD mit 500 GB gegen eine SSD mit 1TB ausgetauscht. Nach dem Tausch funktionierte der Bootlader nur noch im abgesicherten Modus.
Erst als ich die fstab geändert habe, konnte ich mich als normaler Benutzer wieder anmelden. Ist das normal?

Ja, das ist normal, weil die /etc/fstab in der Regel die UUIDs der Dateisysteme verwendet.
Legst du ein neues Dateisystem an (mkfs), wird auch eine neue UUID erstellt, außer: Du übergibst die bisherige UUID dem mkfs-Kommando als Option.

egweber1 schrieb:
Die Platte soll hauptsächlich Videos beinhalten. Mit welchem Dateisystem formatiere ich die Platte am besten?

Ich empfehle dir xfs. Bei ext4 würde mit der Standardeinstellung aus /etc/mke2fs.conf sofort eine ganze Schiffsladung an Inodes auf die Festplatte geschrieben, von denen du mit Videodateien nicht mal 1‰ benötigen würdest.
lg Christina

egweber1 · 6 Dez. 2022

Habe ich mit YAST-Partitionierer und xfs versucht. Bleibt bei 40% stehen. Nach einer halben Stunde neu gestartet. Mit GPartet nach einer halben Stunde erfolgreich. Dauert das bei einer SSD länger?
Eine Platte mit Sicherung habe ich neu formatiert. Habe aber jetzt nur als su Schreibzugriff auf sdb1 und sdc1. Vorher war die Platte unter Leap eingehängt. Jetzt Tumbleweed.
Habe zum Formatieren Daten und ISV-Anwendungen gewählt, Dann Partitions-ID: Linux gewählt. Wie bekomme ich wieder als normaler Benutzer Schreibzugriff auf die Platte? Windows-Platte kann ich ja auch noch normal benutzen. Habe aber daran auch nichts verändert.
Anbei fstab:

Code:

/dev/nvme1n1p2  /                       btrfs    defaults                      0  0
/dev/nvme1n1p2  /var                    btrfs    subvol=/@/var                 0  0
/dev/nvme1n1p2  /root                   btrfs    subvol=/@/root                0  0
/dev/nvme1n1p2  /boot/grub2/x86_64-efi  btrfs    subvol=/@/boot/grub2/x86_64-efi  0  0
/dev/nvme1n1p2  /boot/grub2/i386-pc     btrfs    subvol=/@/boot/grub2/i386-pc  0  0
/dev/nvme1n1p2  /.snapshots             btrfs    subvol=/@/.snapshots          0  0
/dev/nvme1n1p5  /home                   btrfs    defaults                      0  0
/dev/nvme1n1p4  /boot/efi               vfat     utf8                          0  2
/dev/sda2       /Windows                ntfs-3g  user,users,gid=users,fmask=113,dmask=002,locale=en_US.UTF-8  0  0
/dev/sdb1       /Sicherung              xfs      defaults                      0  0
/dev/sdc1       /Daten                  xfs      defaults                      0  0

sdc ist die neue Platte.

egweber1 · 6 Dez. 2022

So, bei Sicherung und Daten Berechtigungen: Benutzer auf Root, Gruppe auf users und Eigentümer und Gruppe auf: Anzeige und Änderung des Inhalts möglich. Erledigt! Danke.

Christina · 6 Dez. 2022

egweber1 schrieb:
Habe ich mit YAST-Partitionierer und xfs versucht. Bleibt bei 40% stehen. Nach einer halben Stunde neu gestartet. Mit GPartet nach einer halben Stunde erfolgreich. Dauert das bei einer SSD länger?

Bei einer 1TB großen SSD ist das normalerweise in wenigen Sekunden erledigt. Eine 1TB-HDD braucht ein paar Sekunden länger.

egweber1 schrieb:
Eine Platte mit Sicherung habe ich neu formatiert. Habe aber jetzt nur als su Schreibzugriff auf sdb1 und sdc1. Vorher war die Platte unter Leap eingehängt. Jetzt Tumbleweed.
Habe zum Formatieren Daten und ISV-Anwendungen gewählt, Dann Partitions-ID: Linux gewählt. Wie bekomme ich wieder als normaler Benutzer Schreibzugriff auf die Platte?

Sobald ein neues Linux-Dateisystem angelegt wird, ist immer root für Besitzer & Gruppe eingestellt.

Beim NTFS-Dateisystem (/dev/sda2) hast du per gid=users,fmask=113,dmask=002 den Schreibzugriff für alle Mitglieder der Gruppe users hergestellt.

egweber1 schrieb:

Anbei fstab:

Code:

(…)
/dev/nvme1n1p4  /boot/efi               vfat     utf8                          0  2
/dev/sda2       /Windows                ntfs-3g  user,users,gid=users,fmask=113,dmask=002,locale=en_US.UTF-8  0  0
/dev/sdb1       /Sicherung              xfs      defaults                      0  0
/dev/sdc1       /Daten                  xfs      defaults                      0  0

sdc ist die neue Platte.

Gerätenamen in der /etc/fstab haben den Nachteil, dass deren Zuordnung nicht mehr stimmt, sobald sie vom Kernel beim Booten in einer anderen Reihenfolge erkannt werden.
Genau deswegen wird meistens die UUID des Dateisystems eingetragen. Du kannst aber auch LABEL oder /dev/disk/by-id/… verwenden.

lg Christina

josef-wien · 6 Dez. 2022

egweber1 schrieb:
Benutzer auf Root, Gruppe auf users und Eigentümer und Gruppe auf: Anzeige und Änderung des Inhalts möglich.

Ich halte das nicht für eine glückliche Lösung. Wenn beim Kopieren die ursprünglichen Berechtigungen beibehalten werden, wird es in der Regel funktionieren, aber in Anlehnung an Murphy kann es trotzdem irgendwann zu einem Problem kommen (vor allem wenn für das übergeordnete Verzeichnis die Schreibberechtigung für die Gruppe wegfallen sollte). Wenn beim Kopieren die ursprünglichen Berechtigungen nicht beibehalten werden, werden die Berechtigungen des Zielordners unter Berücksichtigung der umask erteilt, und diese enthält üblicherweise keine Schreibberechtigung für die Gruppe.

Wenn es nur einen Benutzer gibt, kannst Du diesen als Eigentümer des Dateisystems definieren. Bei mehreren Benutzern solltest Du wie beim Heimatverzeichnis für jeden Benutzer einen Ordner anlegen.

Nachtrag: Korrektur des Inhalts.

Christina · 7 Dez. 2022

egweber1 schrieb:
Habe ich mit YAST-Partitionierer und xfs versucht. Bleibt bei 40% stehen. Nach einer halben Stunde neu gestartet. Mit GPartet nach einer halben Stunde erfolgreich. Dauert das bei einer SSD länger?

Ich habe das jetzt mit einer günstigen 240GB-SSD selber ausprobiert, wie lange es dauert, bis ein XFS-Dateisystem angelegt ist.
Die (SATA) SSD ist nur per SuperSpeed USB 5 Gb/s angeschlossen.

• Disklabel & 1 Partition anlegen dauert effektiv keine Sekunde.
parted /dev/sdh mklabel msdos
sfdisk /dev/sdh -N 1(…)
• XFS-Dateisystem anlegen:

Rich (BBCode):

$ time mkfs.xfs -L 'Crucial_240' /dev/sdh1
meta-data=/dev/sdh1              isize=512    agcount=4, agsize=14651840 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=58607360, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=28616, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Discarding blocks...Done.

real    0m11.655s
user    0m0.012s
sys    0m0.000s

Bei einer flotten 1TB-SSD, die per SATA 6 Gb/s angeschlossen ist, sollte das also unter 45 Sekunden dauern.
Ansonsten liegt entweder ein Hardwaredefekt vor oder das verwendete Programm funktioniert nicht wie es sollte.

marce · 7 Dez. 2022

Gibt's da auch so ein Häckchen in der Art von "Schnellformatieren vs. komplett formatieren" (wie unter Windows)? Das könnte den Zeitbedarf bei einer 1TB-SSD erklären...

Christina · 7 Dez. 2022

marce schrieb:
"Schnellformatieren vs. komplett formatieren"

Wie willst du eine Festplatte, HDD oder SSD, formatieren?
Für antiquierte Disketten gibt es das Kommando fdformat.

josef-wien · 8 Dez. 2022

egweber1 schrieb:
YAST-Partitionierer

egweber1 schrieb:
GPartet

Der Nachteil von grafischen Oberflächen liegt darin, daß man nie weiß, was sie im Detail machen (d. h. mit welchen Parametern die Formatierung erfolgt).

Wenn das Medium aus Deiner Sicht normal funktioniert, würde ich nicht zuviel darüber nachdenken.

marce · 8 Dez. 2022

Christina schrieb:
Wie willst du eine Festplatte, HDD oder SSD, formatieren?
Für antiquierte Disketten gibt es das Kommando fdformat.

meinereiner macht das immer an der Konsole mit mkfs.*

... mag ja aber sein, daß es in irgendeiner GUI ein Tool zum Formatieren gibt, das noch die Option des "Datenträgers während des Formatierens auch gleich nullen" bietet - und dann könnte wie gesagt, wenn man das Häkchen setzt, ein entsprechender Zeitaufwand dabei raus kommen...

egweber1 · 8 Dez. 2022

Hab ich mit GParted formatiert. Ansonsten ging es auch immer viel schneller mit normalen HDD oder USB-Stick oder auch NVME-Platten.
Macht auch nur zum Beispiel:

Code:

mkntfs -Q -v -F -L " '/dev/sde1'

Christina · 8 Dez. 2022

egweber1 schrieb:
Hab ich mit GParted formatiert. (…)

Code:

mkntfs -Q -v -F -L " '/dev/sde1'

manpage mkntfs:

Basic options
-f, --fast, -Q, --quick
Perform quick (fast) format. This will skip both zeroing of the volume and bad sector checking.

mkfs.xfs kennt eine solche Option nicht. (xfsprogs Version 6.0.0)
Eine SSD würde ich eh nicht auf diese Art und Weise überprüfen.

Christina · 11 Dez. 2022

egweber1 schrieb:
Vorher war die Platte unter Leap eingehängt. Jetzt Tumbleweed.

Hi Eddie,

verwendest du beides: openSUSE Leap und openSUSE Tumbleweed?
Was mir dazu noch einfällt, sind die entsprechenden xfsprogs-Versionen. Poste mal bitte jeweils diese Ausgabe:

Code:

zypper search --details xfsprogs libhandle

lg Christina

egweber1 · 11 Dez. 2022

Nur noch Tumbleweed. Vorher hatte ich Leap.
Hier die Ausgabe von :

zypper search --details xfsprogs libhandle

Code:

S  | Name                 | Type       | Version   | Arch   | Repository
---+----------------------+------------+-----------+--------+---------------------------
| libhandle1 | Paket | 6.0.0-1.1 | x86_64 | Haupt-Repository (OSS)
| libhandle1 | Paket | 6.0.0-1.1 | i586   | Haupt-Repository (OSS)
| libhandle1-debuginfo | Paket | 6.0.0-1.1 | x86_64 | openSUSE-Tumbleweed-Debug
| libhandle1-debuginfo | Paket | 6.0.0-1.1 | i586   | openSUSE-Tumbleweed-Debug
i+ | xfsprogs | Paket | 6.0.0-1.1 | x86_64 | Haupt-Repository (OSS)
v | xfsprogs | Paket | 6.0.0-1.1 | i586   | Haupt-Repository (OSS)
| xfsprogs | Quellpaket | 6.0.0-1.1 | noarch | openSUSE-Tumbleweed-Source
| xfsprogs-debuginfo | Paket | 6.0.0-1.1 | x86_64 | openSUSE-Tumbleweed-Debug
| xfsprogs-debuginfo | Paket | 6.0.0-1.1 | i586   | openSUSE-Tumbleweed-Debug
| xfsprogs-debugsource | Paket | 6.0.0-1.1 | x86_64 | openSUSE-Tumbleweed-Debug
| xfsprogs-debugsource | Paket | 6.0.0-1.1 | i586   | openSUSE-Tumbleweed-Debug
| xfsprogs-devel | Paket | 6.0.0-1.1 | x86_64 | Haupt-Repository (OSS)
| xfsprogs-devel | Paket | 6.0.0-1.1 | i586   | Haupt-Repository (OSS)
| xfsprogs-scrub | Paket | 6.0.0-1.1 | x86_64 | Haupt-Repository (OSS)
| xfsprogs-scrub | Paket | 6.0.0-1.1 | i586   | Haupt-Repository (OSS)

Christina · 11 Dez. 2022

libhandle1 ist noch nicht installiert.
Als root:

Code:

zypper install libhandle1

Du kannst deine XFS-Dateisysteme einfach mal überprüfen:
Als root:

Code:

umount /Sicherung
xfs_repair /dev/sdb1
xfs_info /dev/sdb1
mount /Sicherung

Und:

Code:

umount /Daten
xfs_repair /dev/sdc1
xfs_info /dev/sdc1
mount /Daten

Die Ausgabe am besten in zwei getrennte Code-Tags, dann ist es übersichtlicher.
Lg Christina

egweber1 · 24 Dez. 2022

Sicherung:

Code:

Tumbleweed:~ # umount /Sicherung
Tumbleweed:~ # xfs_repair /dev/sdb1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 3
        - agno = 2
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
Tumbleweed:~ # mount /Sicherung

Daten:

Code:

Tumbleweed:~ # umount /Daten
Tumbleweed:~ # xfs_repair /dev/sdc1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 3
        - agno = 2
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
Tumbleweed:~ # xfs_info /dev/sdc1
meta-data=/dev/sdc1              isize=512    agcount=4, agsize=61047552 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=244190208, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=119233, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Tumbleweed:~ # mount /Daten

Christina · 26 Dez. 2022

Hi Eddie,
soweit sieht alles sehr gut aus: Alle aktuellen Features bigtime, inobtcount sind gesetzt; nrext64 ist noch experimentell.

Falls du mal wieder das Problem hast:

egweber1 schrieb:
Habe ich mit YAST-Partitionierer und xfs versucht. Bleibt bei 40% stehen. Nach einer halben Stunde neu gestartet. Mit GPartet nach einer halben Stunde erfolgreich.

Schaue als root mit iotop -o oder iotop -bo nach, welcher Prozess oder welches Kommando da ein halbe Stunde lang die SSD / HDD blockiert.
Kein Dateisystem benötigt so viel Zeit fürs Anlegen bei einer 1TB großen Partition (bsize=4096 blocks=244190208).

lg Christina