[fbsd] gb begrenzung für fsck_msdosfs?

d4mi4n

d4mi4n

volksoperator on duty
hi *,
nachdem ich versucht hatte meine 97gb fat32 partition in freebsd mit fsck_msdosfs zu bearbeiten habe ich immer folgende Fehlermeldung erhalten:
*werde ich morgen noch einfügen, habe ich gerade nicht im kopf*

verkleinert auf 80gb gibt es keinerlei probleme. jetzt die frage:
gibt es etwas für fsck, dass mit MSDOSFS_LARGE für mount_msdosfs zu vergleichen ist, welches die gb grenze anhebt?

oder kann es ein anderes problem sein, ausser der gb grenze, warum fsck_msdosfs keine 97gb checken will?

auszug aus 5.3 release notes:

Die neue Kernel Option MSDOSFS_LARGE dient zur Unterstützung von FAT32 Dateisystemen, die größer sind als 128GB. Diese Option ist standardmäßig inaktiv. Bitte beachten Sie, daß die Option 32 Byte Kernel-Speicher für jede einzelne Datei im Dateisystem verbraucht. Sie sollten diese Option nur in Ausnahmefällen nutzen, z.B. für den Nur-Lese-Zugriff auf Dateisysteme mit weniger als einer Million Dateien. Außerdem ist es nicht möglich, diese Dateisysteme über NFS zu exportieren.
 
Hehe :)

Wenn ich dein Problem nun richtig deute, könntest du mehr Arbeitsspeicher einstecken. Leider benötigt fsck für jedes Gigabyte Plattenspeicher eine ganze Menge RAM. Irgendwann ist dieser voll -> fsck bricht ab. Für UFS wurde vor einiger Zeit, wie wir hier in einem anderen Thread festgestellt haben, dass Speicherverhalten so geändert, dass fsck dort immer mit 1 - 2 Gigabyte RAM auszukommen scheint.

Bei fsck_msdosfs hat man so eine Änderung nicht vorgenommen, oder sie ist nicht möglich. Das ist in sofern eklig, da man FAT Dateisysteme meiner Erfahnrung nach sehr häufig checken sollte und deshalb nicht immer gleich Windows starten möchte.

Mein Vorschlag daher, wenn er vielleicht auch nicht das ist, was du möchtest:
1. Zerhacke den Slice mit dem FAT in kleinere Teile. Löst dein Problem und macht vor allem deine Daten ein wenig sicherer, da nur eine Hälfte des zerhacken Slice auf einmal abraucht ;)
2. Nimm Ext2FS. Es kann unter Windows / Linux / FreeBSD einwandfrei gelesen und geschrieben werden und ist - wenigstens solange der Rechner nicht abstürzt - deutlich sicherer und schneller als FAT.
 
fsck_msdosfs: und es tut doch auch auf großen FAT32 Partitionen!

Mhm, wat riecht denn hier so streng?
Ist es etwas ein alter Thread?
Wie auch immer,
die alten Filesystemsünden, wie z.B FAT Filesystem
gehen einem ja oft noch jahrelang nach. :ugly:

Habe seit einigen Tagen mit alten FAT32 Partitionen rumhantiert.
Erstaunlich ist, das Windows wohl besondres unsauber fsc...
...äh "scandisken" oder "chkdsk" tut, oder wie auch immer das da gerade da heißen mag.
Jedenfalls hat mein FreeBSD 6.2-STABLE
die von Windows "behandelten" FAT32 Partitonen immer so dermaßen ekelig gefunden,
das fsck_msdosfs die Pflege der FAT32 Partitonen immer verweigert hatte.
(mounten ließen die sich aber trotzdem, robust ist es ja, das alte FAT)

Aber ich habe das fsck_msdosfs gerade erfolgreich ausgetrickst
und es hat die gammeligen FAT32 Partitonen gerade gepflegt, oh ja! :)
Der Trick ist,
fsck_msdosfs im Preen Mode zu zwingen die ekelige FAT32 Partition
auf jeden Fall zu pflegen. :D
Also z.B.:
Code: 
fsck_msdosfs -fp /dev/ad3s1
Und das hat es sogar mit einer 160 GB Festplatte mit einer einzigen fetten FAT32 Partition gemacht!

Ihr habt vermutlich keine Ahnung, wie lange mich das schon gewaltig gestört hatte
das ich FAT Partitionen nicht fsck-en konnte.
Windows ist nämlich quasi geradzeu ein Dreckspatz,
das macht nie ordentlich sauber.

Mal stimmt das Backup der FAT nicht überein
mal hinterlässt es unpassende Dateien was wohl irgendwie mit
dem Ding mit den langen Dateinamen zusammenhängt.

Während das FreeBSD fsck_msdosfs dann noch nicht mal dranwollte,
erkannte das fsck für FAT von Linux die Fehler, lief auch drüber, konnte es aber nicht reparieren.
Windows ist das irgendwie alles sowas von egal. :ugly:

Aber ich habe z.B. eine FAT32 Partiton, auf die ich Emails und Lesezeichen abspeichere,
damit ich da von FreeBSD, Linux und Windows aus darauf zugreifen kann.
Außerdem benutze ich diese FAT32 Partiton zum Austausch von Dateien
die ich auch unter allen Systemen verfügbar haben möchte.
Und nie konnte ich diese ranzige FAT32 Partiton ordentlich fsck-en.
Aber endlich habe ich rausgefunden, wie ich das FreeBSD fsck_msdosfs austricksen kann. ;)
Und irgendwie habe ich das Gefühl, nun werden große Verzeichnisse mit
viel Zeug darin schneller eingelesen.
Kann aber auch sein, das es Einbildung ist, aber ein gutes Gefühl ist es schon,
wenn man solche Meldungen vom FreeBSD fsck_msdosfs gelesen hat:
/dev/ad3s1: Invalid long filename entry for /foo
/dev/ad3s1: Invalid long filename entry for /foo/blaa
/dev/ad3s1: Invalid long filename entry for /foo/tralala
/dev/ad3s1: Invalid long filename entry for /foo/nochwas
/dev/ad3s1: Invalid long filename entry for /und/nochirgend/was
/dev/ad3s1: Invalid long filename entry for /ach/da/is/ja/noch/einer
/dev/ad3s1: Invalid long filename entry for /hoffentlich/ham/4/es/bald/mal
Zum Vergrößern anklicken....

Anschließend lief dann auch:
Code: 
fsck_msdosfs -y /dev/ad3s1
mit dem erlösenden krönenden Abschluß über die 160 GB FAT32 Partiton:
Code: 
MARK FILE SYSTEM CLEAN? yes
MARKING FILE SYSTEM CLEAN

***** FILE SYSTEM WAS MODIFIED *****

Und dann noch mal zum versichern:
Code: 
fsck_msdosfs -p /dev/ad3s1
/dev/ad3s1: FILESYSTEM CLEAN; SKIPPING CHECKS

Jaaa! :)
Alles wird gut. ;)
(Ganz schön erfreulich schnell ist das FreeBSD fsck_msdosfs übrigens auch noch)


Gruß, Fusselbär
 
Zuletzt bearbeitet:
MrFixit schrieb:
Will man FAT32 denn noch verwenden, wo ntfs-3g doch sauber tut (langsam, aber es tut).
Zum Vergrößern anklicken....

Hm, es ist bei mir zum Teil Gewohnheit,
eine Altlast aus Windows Zeiten, das ich FAT32 Partitionen habe,
welche ich aus Kompatibilitätsgründen behalten habe
zum Austausch von Daten über verschiedene Betriebsysteme hinweg.
Habe nämlich nur ein Kiste hier stehen,
wo ich je nachdem, was ich benutzen möchte, die Festplatte
für das Betriebssystem austausche (Wechselfestplatte).

Bei NTFS gibt es bestimmt neue Probleme,
zum Beispiel sowas wie fsck für NTFS:
gibt es das überhaupt und funktioniert das zuverlässig?
Bin ja ganz erfreut, das es jetzt das fsck_msdofs für FAT32 bei mir tut. :)

Im Bekanntenkreis sah ich inzwischen (bei nur Windows Nutzern)
schon mehrere unrettbar kappute NTFS Partitionen nach Hardresets.
Dieses primitive FAT dagegen habe ich mit unzähligen Hardresets
auf Windows nicht klein gekriegt. :ugly:
Kommt ja schon mal gerne bei Zockerei von 3D Spielen vor,
das nichts mehr außer einem Hardreset geht.
Auch Hardresets mit FreeBSD und Linux wenn dabei
FAT Partitionen gemountet waren, hatte das FAT gut überstanden.
Von den Benutzerechtsverwaltung tun sich die beiden Microsoft
Dateisystemformate unter FreeBSD oder Linux doch auch nichts,
da würde also NTFS wohl keinerlei Vorteile bringen.

Da würde ich dann doch lieber zu einem Dateisystem aus dem OpenSource
Bereich tendieren, wenn ich mal das Dateisystem upgrade.
Aber zum Beispiel bei ext2 schreckt mich,
das unter Windows keine Möglichkeit für ein fsck besteht.
So lange, bis ich mich entschieden habe, wovon ich wirklich Vorteile hätte,
bleibe ich lieber bei FAT32, für den Zugriff mit wechselnden Betriebssystemen,
das tut es ja auch schon lange bei mir,
da kann FAT32 also ruhig noch eine weile weiter bei mir in Benutzung bleiben.

Am liebsten würde ich ja ganz auf UFS2 umstellen,
aber das wäre wohl erst recht schwierig, wenn ich UFS2 unter verschiedenen
Betriebssystemen nutzen wollte. ;)


Gruß, Fusselbär
 
> Im Bekanntenkreis sah ich inzwischen (bei nur Windows Nutzern)
> schon mehrere unrettbar kappute NTFS Partitionen nach Hardresets.
> Dieses primitive FAT dagegen habe ich mit unzähligen Hardresets
> auf Windows nicht klein gekriegt.

Also, das halte ich für ein Gerücht.
NTFS klein zu kriegen ist deutlich schwerer, als das bei FAT zu erreichen.

So long...

Der Indy
 
schön zu lesen das :D
aber mittlerweile hab ich ja alles auf ext2 umgestellt.
wie schon beschrieben, existiert kein fsck unter windows, schade eigentlich.
mal überlegen, ob ich nicht doch wieder zu fat zurück wechsel.
macht mir mal jemand zfs für windows? :D
 
indy schrieb:
> Im Bekanntenkreis sah ich inzwischen (bei nur Windows Nutzern)
> schon mehrere unrettbar kappute NTFS Partitionen nach Hardresets.
> Dieses primitive FAT dagegen habe ich mit unzähligen Hardresets
> auf Windows nicht klein gekriegt.

Also, das halte ich für ein Gerücht.
NTFS klein zu kriegen ist deutlich schwerer, als das bei FAT zu erreichen.
Zum Vergrößern anklicken....

Ein Freund hatte mich um Hilfe gebeten als er sein NTFS gründlich verb0rkt hatte,
es waren zuvor jedoch auch schon andere Helfende daran (gescheitert).
Ich bin da jedenfalls siegesgewiss mit einer Windows Live CD auf Basis
von WinPE von Bart Lagerweij
angetappst gekommen und dachte mir: "wird doch ein klacks",
NTFS soll ja so toll sein, aber Pustekuchen, der Filesystemcheck hat Stunden gedauert,
hat ein bißchen was geschafft zu reparieren, vieles jedoch nicht!

Wenigstens ließ sich danach noch von einem Linux aus,
die allermeisten Daten retten, Backups gab es selbstverständlich nicht :D,
so das der Freund trotzdem ziemlich glücklich war,
die meisten seiner Daten noch retten zu können.

Aber eine Windows Neuinstallation war trotzdem fällig.
Was er genau gemacht hatte und die vorher Mithelfenden,
war nicht genau zu ermitteln,
mir ist aber aufgefallen, das dieser Freund mit seiner Kiste sehr
ungeduldig ist und nicht zögerte, recht kurz hintereinander sehr resolut den "Reset"
Knopf zu drücken, möglicherweise, man weiß das ja nie,
hatte er damit irgendeine automatische Routine von Windows mehrmals unterbrochen,
während Windows irgendwas selbst versuchte zu richten,
bei Windows sieht man ja nur das Bildchen, anstatt einer informativen Ausgabe,
was gerade im einzelnen beim booten gemacht wird.

Es gibt aber noch einen praktischen Vorteil vom "altmodischen" FAT (32):
DOS kann direkt darauf zugreifen!
Ist schon ganz praktisch, wenn man bei BIOS und Firmwareupdates
sicherheitshalber Backups abspeichern kann,
auch wenn kein Diskettenlaufwerk vohanden ist. ;)

Und wie ist ein Filesystemcheck von NTFS
von FreeBSD und/oder Linux aus zu bewerkstelligen?
So weit ich weiß, arbeiten Tools wie Parted Magic (eine Linux Live CD mit gparted)
mit ntfsfix, was die NTFS Partition als "dirty" markiert
und damit das NTFS überprüfen an Windows abdelegiert, wenn das NTFS
das nächste mal von Windows gemountet wird.


Gruß, Fusselbär
 
Das Problem beim NTFS ist, dass es auch wirklich endgültig hinüber ist, wenn es denn mal kaputt geht. Eine Reparatur ist nur in den seltensten Fällen noch möglich.

Da NTFS Journals sollte (bitte Theorie und Praxis unterscheiden) ein Dateisystemcheck nie nötig sein. Wenn man ihn doch machen muss, muss man Windows starten oder seine CD mit dem Programm zum Reparieren. Sowas gibts z.B. kostenlos von Avira.
 
> Ein Freund hatte mich um Hilfe gebeten als er sein NTFS gründlich verb0rkt hatte,
> es waren zuvor jedoch auch schon andere Helfende daran (gescheitert).
> ...
Genau das ist meistens das Problem.
Es gibt zu viele selbst ernannte Experten, die Dinge kaputtreparieren.

Ich habe mich vor einigen Jahren mal etwas intensiver mit NTFS beschäftigt und
denke daher, das es ein gutes Dateisystem ist.

> Das Problem beim NTFS ist, dass es auch wirklich endgültig hinüber ist, wenn es
> denn mal kaputt geht. Eine Reparatur ist nur in den seltensten Fällen noch
> möglich.
Man muß sich aber schon sehr bemühen, um es kaputt zu machen.
Bei FAT ist das deutlich einfacher. ;-)

So long...

Der Indy
 
Achja, die guten alten Dateisysteme. Ich weiss auch nicht wirklich, was ich fuer den Dateiaustausch zwischen den Betriebssystemen verwenden soll. Am liebsten waere mir ja ext2fs. Schliesslich gibt es fuer Windows mittlerweile Erweiterungen zum Lesen und Schreiben und fuer Linux ist das ja ohnehin kein Problem. Aber ich moechte bei FreeBSD keinen eigenen Kernel bauen weil mir GENERIC sonst vollkommen zureicht und ich gerne freebsd-update nutzen moechte. Was soll man da also tun? FAT32 waere natuerlich eine Option aber das ist... nunja, wirklich ranzig. Da stellt sich mir die Frage warum ext2fs nicht in GENERIC drin ist. Kann da jemand was genaueres sagen? Ich finde es ein wenig verqueer, wenn sich FAT16/32 im Kernel befindet, ext2fs aber nicht.
 
Oh verdammt. Auf diese Frage hin habe ich mal gegoogled und tatsaechlich scheint dem so zu sein. Was mich jetzt natuerlich nervt: jeder Guide, den ich dazu gelesen habe, besagte dass man den Kernel neu bauen soll. GRAR! Wieder einmal danke an Kamikaze fuer einen hilfreichen Hinweis. :)
 
Inzwischen gibt es sogar atapicam als Kernel Modul, so dass man zum Brennen nicht mehr einen neuen Kernel braucht. Da hat sich im letzten Jahr still und leise einiges getan.
 
Ja, mit 6.2 wurden einige ganz wesentliche Sachen als Modul zur Verfügung gestellt. Darunter auch die ganze Parallelport-Geschichte, leider noch außer puc(4). Aber das wird sich mit 7.0 auch ändern :)
 
Na super! Dann gibt es ja eigentlich, genau genommen, nur noch sehr wenige Gruende, GENERIC nicht zu verwenden. Oder wie sehen die alteingesessenen User das?

Hm. Die Frage ist natuerlich ziemlich Off-Topic. Wuerde mich aber dennoch interessieren also antwortet doch einfach als PM. :)
 
Für meinen Geschmack ist in GENERIC immer noch zu viel Kram drin, den ich nicht brauche. Natürlich werden die ganzen SCSI- und Raid-Controller benötigt, ein GENERIC soll ja so ziemlich überall booten. Aber auf meinen Systemen kommentier ich dann doch einiges davon aus.

Das bringt keine Performance-Verbesserungen und ich glaube die Größe des Kernels wird dadurch auch nur marginal geringer. Deswegen ist das im Grunde genommen blödsinn. Aber ich kann's einfach nicht lassen. Außerdem ist altq für PF nicht in GENERIC.
 
Offiziell werden wir das natürlich nie sehen, aber ich verwende auf meinen Rechnern immer den minimalst möglichen Kernel und lade ausnahmslos alles - von ata bis usb - per Modul rein. Da kann ich bei Löchern auch schnell mal ein Modul rekompilieren und erneut laden ohne das System neustarten zu müssen :)
 
Heißt das du bootest von SCSI-Platten? Oder kann man tatsächlich ohne ATA-Treiber von ATA-Platten booten?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben