• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Gelöst Festplattenwechsel Dateisystem

egweber1

Hacker
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.
 
Zuletzt bearbeitet:

marce

Guru
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

Moderator
Teammitglied
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.

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
 
OP
egweber1

egweber1

Hacker
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.
 
Zuletzt bearbeitet von einem Moderator:
OP
egweber1

egweber1

Hacker
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

Moderator
Teammitglied
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.

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.

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

Ultimate Guru
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.
 
Zuletzt bearbeitet:

Christina

Moderator
Teammitglied
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

Guru
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...
 

marce

Guru
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...
 
OP
egweber1

egweber1

Hacker
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

Moderator
Teammitglied
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

Moderator
Teammitglied
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
 
OP
egweber1

egweber1

Hacker
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

Moderator
Teammitglied
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
 
OP
egweber1

egweber1

Hacker
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

Moderator
Teammitglied
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:
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
 
Oben