Merkwürdiges Partitionsproblem, was machen?

[dirk11]

Hi Leute,

ich hab mehr oder weniger durch Zufall eine Meldung im syslog entdeckt, deshalb mal für eine Partition fsck laufen lassen. Dabei ist folgendes herauskgekommen:

Code: Alles auswählen

# fsck.vfat /dev/sda5
dosfsck 3.0.13, 30 Jun 2012, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 3
/dev/sda5: 5704 files, 686694/1220011 clusters

WTF will das da von mir? So ein Problem habe ich noch nie gehabt. Was tun, welche Option ist die richtige? Auf die Daten von sda5 kommts mir nicht so an, die kann ich wieder rüber kopieren, nur meine anderen Partitionen dürfen davon nicht tangiert werden (sda5 ist die erste logische Partition meiner ssd, danach kommen ein paar wichtige andere logische Partitionen)!!!

[zwiebelchen]

WTF ?

FAT auf ner SSD ?

Wenn du genug Platz hast zum Auslagern:
Ganze SSD leer räumen / wegsichern und ein Linux-Filesystem wählen.

Oder gibt es einen speziellen Grund für FAT ?

[smutbert]

Ich vermute, da geht es um die Dateizuordnungstabelle (FileAllocationTable). Wird das Dateisystem nicht korrekt ausgehängt, kann es passieren, dass Änderungen zwar in die originale FAT, noch nicht aber in die Kopie(n)/Backup(s) der FAT geschrieben wurden.

fsck merkt das dann beim Überprüfen (vermutlich beim Systemstart) und fragt nach was es machen soll:
1. die Änderungen von der Original-FAT in die Backup-FAT(s) übernehmen
2. den vorherigen Zustand der/einer Kopie wiederherstellen und in die Original-FAT schreiben
3. oder alles so lassen wie es ist und nichts unternehmen (dann bleibt der Zustand des Dateisystems inkosistent - dafür hat sich dein System offensichtlich entschieden (ändern läßt sich das Standardverhalten glaube ich in /etc/default/rcS mit FSCKFIX=yes))

Bei der EFI-Systempartition (ebenfalls gezwungenermaßen FAT(32)) ist mir das mit Wheezy ein paar Mal passiert, ohne dass ich herausgefunden hätte wieso, jetzt mit jessie schon lange nicht mehr.

Ich habe in so einem Fall das Dateisystem ausgehängt und fsck manuell ausgeführt, um das Dateisytem wieder in einen konsistenten Zustand zu bringen

Code: Alles auswählen

fsck.vfat -a /dev/sda5

(dann macht er alles automatisch) oder

Code: Alles auswählen

fsck.vfat -r /dev/sda5

dann fragt er wie im Log nach (ich habe immer 1. gewählt).

Ah ja und ich würde FAT auch nur mehr dann verwenden, wenn es einen triftigen Grund dafür gibt.

[dirk11]

WTF ?
FAT auf ner SSD ?

Ja, warum denn nicht? Ist/war für bestimmte Sachen der kleinste gemeinsame Nenner.

Wenn du genug Platz hast zum Auslagern:
Ganze SSD leer räumen / wegsichern und ein Linux-Filesystem wählen.

Äh, warum sollte ich das machen? Das ist eine von sieben Partitionen, wieso soll ich die ganze SSD "leerräumen"? Was haben die anderen Partitionen mit der FAT-Partition zu tun?

Ich vermute, da geht es um die Dateizuordnungstabelle (FileAllocationTable). Wird das Dateisystem nicht korrekt ausgehängt, kann es passieren, dass Änderungen zwar in die originale FAT, noch nicht aber in die Kopie(n)/Backup(s) der FAT geschrieben wurden.

Aha. Hat denn FAT32 auch einen "Bootsektor"? Das wusste ich nicht.

fsck merkt das dann beim Überprüfen (vermutlich beim Systemstart) und fragt nach was es machen soll:

Ja, der Fehler existiert wohl schon zwei Wochen oder so. Da die Partition bis gestern vollkommen leer/ungenutzt war, ist es mir nicht aufgefallen.

3. oder alles so lassen wie es ist und nichts unternehmen (dann bleibt der Zustand des Dateisystems inkosistent - dafür hat sich dein System offensichtlich entschieden (ändern läßt sich das Standardverhalten glaube ich in /etc/default/rcS mit FSCKFIX=yes))

Fragen wir mal anders: wenn ich mich umentscheide bzw. die Möglichkeit besteht, daraus ein NTFS zu machen, dann ist der Fehler also vollkommen wurscht, weil nach Umformatierung sowieso alles weg ist - inklusive des Fehlers? Weil er nur in der Dateizuordnungstabelle des Dateisystems besteht?
Mich irritierte nur das "boot sector", da hatte ich Angst, dass mir das den MBR meiner SSD zerpflückt und danach alles Fratze ist.

Ah ja und ich würde FAT auch nur mehr dann verwenden, wenn es einen triftigen Grund dafür gibt.

Kann ein XP in einer virtualbox NTFS mounten? Dann würde ich auf NTFS umstellen.

[smutbert]

FAT auf einer SSD ist zB nicht optimal weil es trim/discard nicht unterstützt (?)

Um den MBR brauchst du dir jedenfalls keine Sorgen zu machen, da geht es wirklich nur um den Inhalt dieser einen Partition und wenn du die tatsächlich formatierst, ist das momentan leicht beschädigte Dateisystem komplett egal.
(Das Wort Bootsector hab' ich ursprünglich überlesen - ist aber wurscht Jede Partition hat auch noch einen eigenen Bootsektor, den PartitionBootRecord, um den es hier wohl geht. Für den gilt dann wohl im Wesentlichen das gleiche mit Original und Backup(s) wie für die FAT und es hat keinesfalls etwas mit dem MBR zu tun)

Wenn du XP in einer VirtualBox ausführst, ist das Dateisystem normalerweise egal, denn man könnte zwar wahrscheinlich Windows direkt auf das Blockdevice (=die Partition) zugreifen lassen, aber das ist erstens ein relativ großer Aufwand und zweitens müsste man es in weiterer Folge tunlichst vermeiden gleichzeitig von Linux und Windows aus auf dieses Dateisystem zuzugreifen, was natürlich im höchsten Maße unpraktisch wäre.

Normalerweise greift man deswegen, etwa über die "Shared Folders" von VBox über das (virtuelle) Netzwerk gemeinsam auf einen oder mehrere Ordner samt Unterordnern und Dateien zu. Das Dateisystem selbst liest dann nur Virtualbox bzw. Linux, dh das Dateisystem muss auch nur von Linux unterstützt werden. Das virtualisierte Windows greift darauf zu wie auf eine Netzwerkfreigabe.
Einzig die Zugriffsrechte im Linuxdateisystem können dabei (glaube ich) manchmal etwas lästig sein.

[dirk11]

FAT auf einer SSD ist zB nicht optimal weil es trim/discard nicht unterstützt (?)

Nun, muss es doch auch nicht, so lange genug ungenutzter, sprich leerer Bereich übrigbleibt, oder? trim/discard hätte sonst sowieso ein Problem, denn verschlüsselte Partitionen machen das auch nicht. Nach dem, was ich vorher gelesen habe, sollte das aber _eigentlich_ mittlerweile egal sein.

Um den MBR brauchst du dir jedenfalls keine Sorgen zu machen,

Gut. Gäbe es an dieser Einstellung in der fstab was zu verbessern?

Code: Alles auswählen

/dev/sda5    /d              ntfs-3g defaults,gid=113,umask=2        0       0

Normalerweise greift man deswegen, etwa über die "Shared Folders" von VBox über das (virtuelle) Netzwerk gemeinsam auf einen oder mehrere Ordner samt Unterordnern und Dateien zu. Das Dateisystem selbst liest dann nur Virtualbox bzw. Linux, dh das Dateisystem muss auch nur von Linux unterstützt werden. Das virtualisierte Windows greift darauf zu wie auf eine Netzwerkfreigabe.
Einzig die Zugriffsrechte im Linuxdateisystem können dabei (glaube ich) manchmal etwas lästig sein.

Ah, gut. Virtualbox ist (noch) nicht aktuell, aber jetzt weiss ich schonmal, wie das funktioniert.

[smutbert]

Was trim angeht magst du recht haben, ich mag den Gedanken es dem SSD-Controller möglichst leicht zu machen, indem ich ihn über frei gewordene Sektoren informiere
Verschlüsselung verwende ich bei meinen Massenspeichermedien nicht, aber ich hätte erwartet, dass zB lvm/luks trim bis zur SSD „durchreichen“ kann (ich bilde mir ein, ich habe schon gelesen, dass es funktioniert - bei RAID beispielsweise funktionierts ja auch - aber wenn ich es selbst nicht verwende merke ich mir solche Dinge auch nicht...)

Wüßte auf Anhieb nichts, was du am fstab-Eintrag verbessern könntest, höchstens vielleicht auch noch noatime als Mountoption setzen. In der Manpage gibt es eine Liste der Mountoptionen, vielleicht findest du ja selbst etwas, was dir nützlich erscheint (wahrscheinlich aber eher nicht): http://linux.die.net/man/8/mount.ntfs-3g

[dirk11]

ich hätte erwartet, dass zB lvm/luks trim bis zur SSD „durchreichen“ kann (ich bilde mir ein, ich habe schon gelesen, dass es funktioniert - bei RAID beispielsweise funktionierts ja auch - aber wenn ich es selbst nicht verwende merke ich mir solche Dinge auch nicht...)

Das wird absichtlich nicht empfohlen, weil es wohl ein Sicherheitsrisiko darstellen könnte.

Wüßte auf Anhieb nichts, was du am fstab-Eintrag verbessern könntest, höchstens vielleicht auch noch noatime als Mountoption setzen.

Dann ist ja alles gut. Ich meine nur mal irgendwo gelesen zu haben, dass NTFS UTF-16 verwendet oder sowas.