On Wed, Nov 06, 2002 at 07:45:20AM +0100, Roland Manfrahs wrote:
> Hallo,
>
> ich betreibe seid kurzem FreeBSD 4.7. Nach der erfolgreichen Installation habe ich unter anderem ein vinum Raid5 volume mit 50 GB Kapazität angelegt. Ich habe dann begonnen, gesicherte Daten in das Raid5 volume zu kopieren. Während der Kopieraktion habe ich ab und an das Kommando df ausgeführt. Dabei ist folgendes Verhalten aufgetreten.
> Als laut Ausgabe df 61% des Volume benutzt waren, ist die Anzeige des benutzten Speicherplatzes auf 60% zurückgesprungen. Dann funktionierte df anscheinend wieder normal bis die 61% Marke überschritten worden ist. Die Ausgabe meldete dann plötzlich, dass wieder nur 60% des volumes belegt seien. Das hat sich solange wiederholt, bis alle Daten kopiert waren.
> Handelt es sich um einen Fehler in df? Soweit ich das prüfen konnte, sind alle Daten korrekt in das volume kopiert worden.
> Gibt es ausser dem Kommando df noch eine andere Möglichkeit festzustellen, wieviel Platz eines vinum volumes noch frei ist (Mal abgesehen von einem shell skript, mit dem man selbst die belegte Kapazität ermitteln kann)?
Ein Vinum Volume hat keinen freien oder belegten Platz - es hat
einfach nur n-Bytes Platz und das wars.
Für die Verwaltung des Platzes ist ausschließlich das Filesystem
verantwortlich - vermutlich UFS.
df ist der richtige Befehl dafür.
Du hast einen Unterschied von 1%, das ist der kleinste Schritt.
Wenn eine Datei geschrieben wird, dann wird quasi vorallociert,
also mehr als die Datei zum jeweiligen Zeitpunkt in Anspruch nimmt.
Wenn die Datei jetzt geschlossen wird, dann wird der zuviel Belegte
Bereich natürlich wieder freigegeben.
Da das Freigeben bei Softupdates verzögert passieren kann mag sich
sogar ein wenig anstauen - das Schreiben der Daten hat halt Priorität.
It's not a bug - it's a feature.
-- B.Walter COSMO-Project http://www.cosmo-project.de ticso(at)cicely.de Usergroup info(at)cosmo-project.de To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Wed 06 Nov 2002 - 09:53:10 CET