growfs: we are not growing (32 bit -> 64 bit)

Wasp

Insektenspray-Gegner
Hi,

soweit ich das mit der bisherigen Recherche richtig verstanden, bzw. mir viel mehr zusammen reimen konnte, kann growfs(8) kein Dateisystem vergrößern, welches hinter dem 2^32-igsten Block liegt. (Bisher unklar geblieben ist für mich, ob das Ende, oder nur der Anfang nicht hinter der genannten Grenze liegen darf.)

Code:
# growfs -N /dev/ad4s3.eli
growfs: we are not growing (52428796->7425605)
(Wie man sieht, gibt es hier anscheinend -- nach wie vor -- einen Überlauf.)

Habe dazu zwei Patches gefunden, welche allerdings beide nicht funktionieren, und bevor ich jetzt selbst damit Zeit verschwende, und die Informationsvielfalt zu dem Thema irgendwo zwischen Lückenhaft und Fehlerhaft rangiert, wollte ich noch mal an hoffentlich Fachkundigere Mitleser, fragen:

  1. Gibts dazu schon irgendwo einen funktionieren und vielleicht sogar getesteten Patch?
  2. Liegt das Problem ausschließlich bei growfs(8) oder müßte in dem Fall noch mehr/tiefer gepatched werden?

Den einen Patch findet man unter: http://masq.tychl.net/growfs.patch . Aber Vorsicht, anscheinend fehlen die ersten paar Zeilen. Desweiteren wird hier eine ältere Version von growfs(8) gepatched. Nach kurzer händischer Korrektur ließ sich der Patch Anwendenden und nach kurzer Kontrolle auch kompilieren. Leider kann ich jedoch das betreffende Dateisystem nach wie vor nicht vergrößern.

Auf Insider-Wissen hofft
Wasp
 
Zuletzt bearbeitet:
Hab derweil schon mal ein wenig in den Quelltext von growfs(8) geschaut, und sowas sieht man doch gerne (growfs.c, Zeile 868):
Code:
 i+sblock.fs_frag<=dmax-cbase;  /* XXX <= or only < ? */
:ugly:

Klar, man kann argumentieren "anscheinend funktionierts doch", aber finde vor einem Release, könnte man das schon mal geklärt haben -- erst Recht nach inzw. vermutlich 5-10 Releases, immerhin ist der Code von mitte 2010 -- und es dann, wo mein weiß, wie es richtig ist, den Kommentar mal entfernen (und den Code ggf. korrigieren).
 
Zurück
Oben