Linux: Verzeichnis lost+found wegkonfigurieren

[Der Martin]

Hallo,

ich weiß, wir haben auch einige Linux/Unix-Fachleute unter uns.

Anscheinend ist es ja üblich, dass Linux auf jeder Partition prophylaktisch ein Verzeichnis "lost+found" anlegt, von dem man hofft, dass man es im Normalbetrieb nie braucht.

Da es also in der Regel unnötig ist, stört es. Zumal es mehrfach auftaucht, wenn man mehrere Partitionen ins Dateisystem einhängt. Ist es also möglich, dieses Verzeichnis umzukonfigurieren? Ich würde gern erreichen, dass nur noch _ein_ Verzeichnis "lost+found" im root-Filesystem existiert, anstatt in jeder Partition separat. Geht das? Wenn ja, wie?

Wenn wir gerade schon bei Linux sind: Üblicherweise führt Linux ja in gewissen Abständen beim Booten ein fsck durch, bevor die Filesysteme gemountet werden. Das dauert je nach Größe des Filesystems und Anzahl der Dateien einige Zeit - bei einem ext3-Filesystem mit rund 300GB, das etwas mehr als 50% voll ist, kann das schon mal eine Viertelstunde sein.
Nun bin ich aber gerade dabei, meinen HTPC für automatisierte timergesteuerte TV-Aufnahmen vorzubereiten. Da wäre es natürlich kontraproduktiv, wenn die Kiste um 22:15 einen Film aufzeichnen soll, per Timer zwei oder fünf Minuten vorher eingeschaltet wird und dann über zehn Minuten zum Booten braucht. Die Zeit, die ein fsck wirklich braucht, ist ja auch leider nicht vorhersehbar. Was könnte ich in diesem Fall tun? Vielleicht fsck beim Booten ganz unterdrücken? Klingt für mich nicht nach einer guten Idee. Aber was dann?

So long,
 Martin

[dedlfix]

Tach!

Anscheinend ist es ja üblich, dass Linux auf jeder Partition prophylaktisch ein Verzeichnis "lost+found" anlegt, von dem man hofft, dass man es im Normalbetrieb nie braucht.

Das ist nicht direkt eine Linux-Geschichte sondern vielmehr eine des gewählten Dateisystems: mindestens ext(2,3,4), vielleicht auch noch andere.

Da es also in der Regel unnötig ist, stört es. Zumal es mehrfach auftaucht, wenn man mehrere Partitionen ins Dateisystem einhängt. Ist es also möglich, dieses Verzeichnis umzukonfigurieren? Ich würde gern erreichen, dass nur noch _ein_ Verzeichnis "lost+found" im root-Filesystem existiert, anstatt in jeder Partition separat.

Da es zum Dateisystem gehört, wird es sich kaum auf ein anderes System auslagern lassen.

Wenn wir gerade schon bei Linux sind: Üblicherweise führt Linux ja in gewissen Abständen beim Booten ein fsck durch, bevor die Filesysteme gemountet werden.

Auch das ist nicht Linux- sondern abhängig vom gewählten Dateisystem.

Nun bin ich aber gerade dabei, meinen HTPC für automatisierte timergesteuerte TV-Aufnahmen vorzubereiten. Da wäre es natürlich kontraproduktiv, wenn die Kiste um 22:15 einen Film aufzeichnen soll, per Timer zwei oder fünf Minuten vorher eingeschaltet wird und dann über zehn Minuten zum Booten braucht.

Nimm ein anderes Dateisystem. Welches die von dir genannten Eigenheiten nicht hat, kann ich dir nicht sagen. (Außer dass ReiserFS kein lost+found hat, aber wie da die aktuellen Empfehlungen sind, entzieht sich meiner Kenntnis.)

dedlfix.

[Der Martin]

Hallo,

Anscheinend ist es ja üblich, dass Linux auf jeder Partition prophylaktisch ein Verzeichnis "lost+found" anlegt, von dem man hofft, dass man es im Normalbetrieb nie braucht.
Das ist nicht direkt eine Linux-Geschichte sondern vielmehr eine des gewählten Dateisystems: mindestens ext(2,3,4), vielleicht auch noch andere.

das ist ein guter Denkanstoß, danke. Da ich bisher nur ext-Dateisysteme verwendet habe (plus FAT32 zum Datenaustausch mit Windows), ist mir das noch nicht aufgefallen. Aber jetzt, wo du es sagst - klar, auf FAT-Dateisystemen macht Linux sowas nicht. Also offensichtlich vom Dateisystem abhängig.

Da es zum Dateisystem gehört, wird es sich kaum auf ein anderes System auslagern lassen.

Auch das leuchtet mir ein - zumal die Dateisystem-Überprüfung ja vor dem Mounten stattfindet, wo das Filesystem also nur ganz allein betrachtet werden kann.

Da wäre es natürlich kontraproduktiv, wenn die Kiste um 22:15 einen Film aufzeichnen soll, per Timer zwei oder fünf Minuten vorher eingeschaltet wird und dann über zehn Minuten zum Booten braucht.
Nimm ein anderes Dateisystem. Welches die von dir genannten Eigenheiten nicht hat, kann ich dir nicht sagen. (Außer dass ReiserFS kein lost+found hat, aber wie da die aktuellen Empfehlungen sind, entzieht sich meiner Kenntnis.)

Gut - aber nach meinen bisherigen Recherchen ist ext4 das einzige stabile Dateisystem, das im Zusammenspiel mit SSDs wirklich empfehlenswert ist. Schade.

Ciao,
 Martin

[Jens Holzkämper]

Tach,

Gut - aber nach meinen bisherigen Recherchen ist ext4 das einzige stabile Dateisystem, das im Zusammenspiel mit SSDs wirklich empfehlenswert ist. Schade.

JFS unterstützt TRIM inzwischen auch, allerdings erst seit dem 3.7er Kernel und XFS kann es schon seit 3.0.

mfg
Woodfighter

[Jörg Reinholz]

Tach!

Post!

Da es zum Dateisystem gehört, wird es sich kaum auf ein anderes System auslagern lassen.

Das Verzeichnis lost+found gehört genau genommen zum Dateisystem auf der Partition. Also zur Partition. Du kannst es nicht verschieben. Das bringt nichts.

Wenn wir gerade schon bei Linux sind: Üblicherweise führt Linux ja in gewissen Abständen beim Booten ein fsck durch, bevor die Filesysteme gemountet werden.

Auch das ist nicht Linux- sondern abhängig vom gewählten Dateisystem.

Das ist schon "Linux". man 5 fstab zu lesen ist ebenso hilfreich wie man 8 mount - insbesondere wegen der in /etc/fstab verwendbaren Optionen. Frag aber lieber nach und stelle Deine Pläne hier vor - und zwar BEVOR Du Mist baust.

Nun bin ich aber gerade dabei, meinen HTPC für automatisierte timergesteuerte TV-Aufnahmen vorzubereiten. Da wäre es natürlich kontraproduktiv, wenn die Kiste um 22:15 einen Film aufzeichnen soll, per Timer zwei oder fünf Minuten vorher eingeschaltet wird und dann über zehn Minuten zum Booten braucht.

Und wie produktiv wäre es wohl den Film aufzuzeichnen und danach festzustellen, dass entweder die neue Datei "im Arsche"(*) ist oder ein paar Dutzend andere?

Ich kann Dir im übrigen versichern, dass Du ein ext4-Dateisystem nur mit dem Einsatz ziemlich brachialer Mittel so kaputt bekommst, dass das Booten "über zehn Minuten" dauert. Der Check geht auch bei großen Partitionen sehr viel schneller.

Die Prüfung findet normalerweise auch statt wenn das System nicht sauber heruntergefahren wurde (brutales Ausschalten etc p.p.)

Jörg Reinholz

*) Mit der Bitte um Nachsicht für mein schlechtes Französisch.

[Der Martin]

Hallo,

Nun bin ich aber gerade dabei, meinen HTPC für automatisierte timergesteuerte TV-Aufnahmen vorzubereiten. Da wäre es natürlich kontraproduktiv, wenn die Kiste um 22:15 einen Film aufzeichnen soll, per Timer zwei oder fünf Minuten vorher eingeschaltet wird und dann über zehn Minuten zum Booten braucht.
Und wie produktiv wäre es wohl den Film aufzuzeichnen und danach festzustellen, dass entweder die neue Datei "im Arsche"(*) ist oder ein paar Dutzend andere?

sagen wir's mal so: Wenn ich eine Partition ausschließlich für Videoaufnahmen einplane (und das ist mein Plan), dann hält sich der Schaden in Grenzen. Das ist ja dann nur eine temporäre Ablage für MPEG-TS-Dateien, bis sie entweder nach dem Anschauen wieder gelöscht oder fürs Archiv in MPEG4 umcodiert werden. Andererseits: Was spräche (theoretisch) dagegen, die Routineüberprüfung nicht beim Booten, sondern beim Herunterfahren des Systems durchzuführen? Das erscheint mir sinnvoller, auch wenn ich im Moment nicht weiß, ob das ein gangbarer Weg ist. Die erzwungene Prüfung nach einem unsauberen Shutdown mag ja davon unberührt sein.

Aber dann habe ich immer noch den nicht vorhersehbaren Zeitbedarf für die gelegentliche Überprüfung der Systempartition (root-Filesystem).

Ich kann Dir im übrigen versichern, dass Du ein ext4-Dateisystem nur mit dem Einsatz ziemlich brachialer Mittel so kaputt bekommst, dass das Booten "über zehn Minuten" dauert. Der Check geht auch bei großen Partitionen sehr viel schneller.

Das ist schon mal gut zu wissen. Bisher habe ich nur Erfahrung mit ext2 (für die boot-Partition) und ext3, und da dauert die Überprüfung tatsächlich eine gefühlte Ewigkeit. Die im OP erwähnte Viertelstunde ist nicht einfach so dahergesagt, sondern Erfahrung aus der Realität (mit ext3).

Ciao,
 Martin

[Jens Holzkämper]

Tach,

Andererseits: Was spräche (theoretisch) dagegen, die Routineüberprüfung nicht beim Booten, sondern beim Herunterfahren des Systems durchzuführen?

das wird vermutlich gehen, ein init-Script, das Mount Count und Maximum Mount Count von allen Partitionen ausliest, die Überprüfung anwirft, falls beide übereinstimmen und danach den Mount Count zurücksetzt.

Aber dann habe ich immer noch den nicht vorhersehbaren Zeitbedarf für die gelegentliche Überprüfung der Systempartition (root-Filesystem).

Warum sollte man das da getrennt vom Rest machen?

Das ist schon mal gut zu wissen. Bisher habe ich nur Erfahrung mit ext2 (für die boot-Partition) und ext3, und da dauert die Überprüfung tatsächlich eine gefühlte Ewigkeit. Die im OP erwähnte Viertelstunde ist nicht einfach so dahergesagt, sondern Erfahrung aus der Realität (mit ext3).

Das klingt nach einer sehr langsamen Festplatte; ext4 ist hier übrigens trotzdem um Größenordnungen schneller.

mfg
Woodfighter

[Der Martin]

Hi,

danke auch für deine Ausführungen.

Aber dann habe ich immer noch den nicht vorhersehbaren Zeitbedarf für die gelegentliche Überprüfung der Systempartition (root-Filesystem).
Warum sollte man das da getrennt vom Rest machen?

auch wieder wahr. Dann bleibt nur noch der erzwungene fsck beim Booten nach einem unsauberen Shutdown, und das ist gut so.[tm]

Die im OP erwähnte Viertelstunde ist nicht einfach so dahergesagt, sondern Erfahrung aus der Realität (mit ext3).
Das klingt nach einer sehr langsamen Festplatte

Den subjektiven Eindruck habe ich sonst eigentlich nicht - in *diesem* Rechner ist es laut 'lshw' eine Seagate "Momentus" (2½", 500GB, 5400/min, SATA-2). Aber ich gebe zu, dass die Geschwindigkeit für mich ein untergeordnetes Kriterium bei der Festplattenauswahl ist; vorrangig sind für mich Geräuschpegel und Stromverbrauch. Diesen PC habe ich außerdem als Komplettpaket gekauft, ohne zu wissen, welche Festplatte da verbaut war.

ext4 ist hier übrigens trotzdem um Größenordnungen schneller.

Das hat Jörg ja auch schon angedeutet, und es deckt sich mit Aussagen, die ich auch hier und da im Internet schon gelesen habe.

JFS unterstützt TRIM inzwischen auch, allerdings erst seit dem 3.7er Kernel und XFS kann es schon seit 3.0.

Von XFS als Alternative habe ich gelesen, aber da war irgendein "Aber", das mich aufhorchen und zu dem Schluss kommen ließ, dass ich das lieber nicht haben möchte - ich weiß aber nicht mehr, was es war. JFS wäre keine Option; bei dem System, um das es geht, reden wir von Mint 13 mit einem 3.2er Kernel. Ich bin übrigens über die Kernel-Entwicklung gar nicht auf dem laufenden, ich dachte, die 3.6er-Generation markiere derzeit die Spitze der Entwicklung. Jetzt lese ich, dass sogar 3.8 schon existiert. Die Jungs sind ja fleißig. :-)

Ciao,
 Martin

[Rudolf]

Ich kann Dir im übrigen versichern, dass Du ein ext4-Dateisystem nur mit dem Einsatz ziemlich brachialer Mittel so kaputt bekommst, dass das Booten "über zehn Minuten" dauert. Der Check geht auch bei großen Partitionen sehr viel schneller.

Ich weiss nicht, was du mit "groß" meinst, aber die Prüfung meiner mit ext4 beschriebenen, etwa zu Dreivierteln gefüllten 2-TByte-Platte braucht eine halbe bis eine Stunde - wohlgemerkt ohne, dass sich fsck über Fehler beklagen täte.

[Der Martin]

Hallo,

Ich kann Dir im übrigen versichern, dass Du ein ext4-Dateisystem nur mit dem Einsatz ziemlich brachialer Mittel so kaputt bekommst, dass das Booten "über zehn Minuten" dauert. Der Check geht auch bei großen Partitionen sehr viel schneller.
Ich weiss nicht, was du mit "groß" meinst, aber die Prüfung meiner mit ext4 beschriebenen, etwa zu Dreivierteln gefüllten 2-TByte-Platte braucht eine halbe bis eine Stunde - wohlgemerkt ohne, dass sich fsck über Fehler beklagen täte.

angenommen, der Zeitbedarf verhielte sich proportional zur Datenmenge auf der Partition, dann würde sich für mein Beispielszenario (300G, davon etwa 150G belegt) etwa ein Zehntel deines Wertes ergeben, also rund 5 Minuten. Das wäre schon erheblich schneller als der tatsächliche Zeitbedarf für meine ext3-Partition.

Allerdings weiß ich nicht genau, wie sich der Zeitbedarf wirklich ergibt. Ich nehme an, dass die Anzahl der Dateien eine größere Rolle spielt als der belegte Speicherplatz, d.h. wenige große Dateien sind vermutlich wesentlich schneller gecheckt als tausende kleine (beim Windows-Check ist das jedenfalls so). Außerdem spielt das Arbeitstempo der Platte eine Rolle - nicht so sehr die maximale Transferrate, aber die Zugriffszeiten, da die Zugriffe ja nicht linear, sondern über den Datenträger verteilt erfolgen.

Ein Vergleich macht daher IMO nur Sinn, wenn man den gleichen Datenbestand auf annähernd gleich großen Partitionen und der gleichen Platte betrachtet. Unter diesen Voraussetzungen will ich der oft gelesenen Aussage, fsck sei gehe ext4 schneller als auf ext3, durchaus Glauben schenken.

Ciao,
 Martin

[Jens Holzkämper]

Tach,

Allerdings weiß ich nicht genau, wie sich der Zeitbedarf wirklich ergibt. Ich nehme an, dass die Anzahl der Dateien eine größere Rolle spielt als der belegte Speicherplatz, d.h. wenige große Dateien sind vermutlich wesentlich schneller gecheckt als tausende kleine (beim Windows-Check ist das jedenfalls so). Außerdem spielt das Arbeitstempo der Platte eine Rolle - nicht so sehr die maximale Transferrate, aber die Zugriffszeiten, da die Zugriffe ja nicht linear, sondern über den Datenträger verteilt erfolgen.

korrekt, die Daten werden beim Check nicht gelesen, ausschließlich die Struktur wird überprüft; die Menge an belegten Inodes spielt also eine wesentlich größere Rolle, als die Datenmenge.

mfg
Woodfighter

[Jörg Reinholz]

Ich weiss nicht, was du mit "groß" meinst, aber die Prüfung meiner mit ext4 beschriebenen, etwa zu Dreivierteln gefüllten 2-TByte-Platte braucht eine halbe bis eine Stunde - wohlgemerkt ohne, dass sich fsck über Fehler beklagen täte.

Ich habe das getestet:

Das Prüfen einer meiner Partitionen, die 1 TB groß, mit ext4 formatiert und zu 50% mit Daten gefüllt ist, dauerte soeben exakt 40 SEKUNDEN. (habe "fsck -f" befohlen - "Force checking even if the file system seems clean.")

Hier die Zeitstempel und Ausgaben:

fastix@trainer:~$ date && sudo fsck -f /dev/sdc1 &&  date
Sa 2. Mär 11:04:02 CET 2013
fsck von util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
backup_intern: 141984/61054976 Dateien (0.7% nicht zusammenhängend), 117898086/244190208 Blöcke
Sa 2. Mär 11:04:42 CET 2013

50 SEKUNDEN dauerte übrigens der Check einer ebenfalls 1TB großen, als Backup benutzten und zu ca. 70% gefüllten XFS-Partition am USB2-Port. Beides liegt bei einem 1/60 Deiner Angaben.

Ich habe definitiv nichts besonderes gemacht. Auch mit anderen und früheren Linux-Versionen habe ich stets vergleichbare Ergebnisse erzielt.

Jörg Reinholz

[Jörg Reinholz]

Ich weiss nicht, was du mit "groß" meinst, aber die Prüfung meiner mit ext4 beschriebenen, etwa zu Dreivierteln gefüllten 2-TByte-Platte braucht eine halbe bis eine Stunde - wohlgemerkt ohne, dass sich fsck über Fehler beklagen täte.

Ich habe das getestet:

Das Prüfen einer meiner Partitionen, die 1 TB groß, mit ext4 formatiert und zu 50% mit Daten gefüllt ist, dauerte soeben exakt 40 SEKUNDEN. (habe "fsck -f" befohlen - "Force checking even if the file system seems clean.")

Hier die Zeitstempel und Ausgaben:

fastix@trainer:~$ date && sudo fsck -f /dev/sdc1 &&  date
Sa 2. Mär 11:04:02 CET 2013
fsck von util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
backup_intern: 141984/61054976 Dateien (0.7% nicht zusammenhängend), 117898086/244190208 Blöcke
Sa 2. Mär 11:04:42 CET 2013

Nachtrag:

Ohne die Option -f geht es natürlich noch sehr viel schneller - weil nur geprüft wird, ob ein "unclear"-bit gesetzt ist:

fastix@trainer:~$ date && sudo umount /dev/sdc1 &&  sudo fsck /dev/sdc1 &&  date
Sa 2. Mär 11:22:32 CET 2013
fsck von util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
backup_intern: sauber, 141984/61054976 Dateien, 117898086/244190208 Blöcke
Sa 2. Mär 11:22:32 CET 2013
fastix@trainer:~$

Das ist übrigens auch das, was beim Booten (vor dem mount, also ohne das umount) auch stattfindet.

Jörg Reinholz

[Rudolf]

Sa 2. Mär 11:04:02 CET 2013
fsck von util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
backup_intern: 141984/61054976 Dateien (0.7% nicht zusammenhängend), 117898086/244190208 Blöcke
Sa 2. Mär 11:04:42 CET 2013

Da kann meine an einem Atombrot hängende WD20EARX nicht mithalten:

Sat Mar  2 19:22:00 CET 2013
fsck from util-linux-ng 2.17.2
e2fsck 1.41.11 (14-Mar-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 106477/122101760 files (2.5% non-contiguous), 371393471/488378633 blocks
Sat Mar  2 20:27:42 CET 2013

[Jörg Reinholz]

Da kann meine an einem Atombrot hängende WD20EARX nicht mithalten:

Das Problem wird kaum die Platte sein. Ich denke, es liegt am "Atombrot", denn bei einem solchen Plattencheck ist durchaus einiges zu berechnen.

Jörg Reinholz

[Rudolf]

Da kann meine an einem Atombrot hängende WD20EARS nicht mithalten:

Das Problem wird kaum die Platte sein. Ich denke, es liegt am "Atombrot", denn bei einem solchen Plattencheck ist durchaus einiges zu berechnen.

Nach reiflicher Überlegung könnte das Problem doch mit der Platte zusammenhängen: Möglicherweise habe ich damals die (einzige) Partition falsch angelegt, d.h. nicht an den intern und klammheimlich von der Platte benutzten 4k-Sektorgrenzen ausgerichtet (nach außen gaukelt sie 512-Byte-Sektoren vor).

[Jens Holzkämper]

Tach,

(Außer dass ReiserFS kein lost+found hat, aber wie da die aktuellen Empfehlungen sind, entzieht sich meiner Kenntnis.)

an Reiser4 wird wohl noch gearbeitet, aber ob das tatsächlich noch irgendwann im Mainstream-Kernel landet, ist offen; im Prinzip arbeitet nur ein Entwickler dran, es wird kaum verwendet http://www.phoronix.com/scan.php?page=article&item=reiser4_linux35&num=1 und mir fällt keine Distri ein, die es unterstützt. Reiser3 erfährt keinerlei Weiterentwicklung sondern höchstens Bugfixes und fällt inzwischen wohl eher unter Legacy; wo es noch läuft muss man es nicht ersetzen, aber es gibt keinen sinnvollen Grund mehr etwas neues damit zu formatieren.

mfg
Woodfighter