Re: Zeit für umount steigt stark

On Wed, Dec 05, 2012 at 05:00:46PM +0100, Marc Santhoff wrote:
> Am Mittwoch, den 05.12.2012, 13:19 +0100 schrieb Bernd Walter:
> > On Wed, Dec 05, 2012 at 11:17:04AM +0100, Lars Engels wrote:
> > > On Wed, Dec 05, 2012 at 09:49:10AM +0100, Marc Santhoff wrote:
> > > > Tag,
> > > >
> > > > bei einem USB-Stöpsel steigt seit wenigen Wochen die benötigte Zeit für
> > > > umount stetig an. Hab jetzt nicht gemessen, aber ich war zwischendurch
> > > > zum humanen Ölwechsel und habe die Katze gefüttert, dann war der erst
> > > > fertig. Mount geht normal schnell.
> > > >
> > > > Drauf ist wie üblich ein DOS-Dateisystem, Zugriffe funktionieren bis
> > > > jetzt gut. Der ist allerdings mit 139 MB von 8 GB recht leer, war das
> > > > aber nicht immer.
> > > >
> > > > Ich vermute der Stick ist defekt, gibt es da Diagnosemöglicheiten?
> > > >
> > >
> > > Rufe umount mal mit truss(1) auf, dann siehst du die syscalls.
> >
> > Das wegschreiben der Cache-Daten passiert nicht per syscal.
> > Meine Vermutung ist, dass der wirklich im schreiben langsammer
> > geworden ist - die Dinger verlieren auch immer mehr Flashblöcke und
> > wenn der Schreibpool erschöpft ist muss der Blöcke löschen, was Zeit
> > braucht.
>
> Kann schon sein, den benutze ich momentan für fast tägliche
> Synchronisierung von eher kleinen Dateien, richtig viele sind das auch
> nicht. Aber sehr oft genau die selben mit kleineren Änderungen.
>
> > Ein globaler delete könnte helfen, falls der die unallocierten Blöcke
> > durch das Schreiben immer mehr zugeordnet hat und nicht durch defekte
> > verlor.
> > Bei einem DOS-Filesystem wird ja im Regelfall immer gleich allociert,
> > d.h. solange das Medium nicht voll geschrieben wird sind die ungenutzten
> > dann ebenfalls im Pool, sobald man einmal voll schreibt sind die hingegen
> > weg.
>
> Hmm, der wurde mal für große Dateibrocken benutzt und war auch des
> öfteren Randvoll. Nun trage ich den mit Arbeitsdateien herum für einen
> Rechner, bei dem ich nichts auf dessen Platte tun will.
>
> > Es gibt sicherlich auch Tools, mit denen man einen delete auf alle
> > vom Filesystem unbelegten Blöcke senden kann.
>
> Ich kann den gern mal leeren und neu formatieren, ggf. auch mit dd
> ausnullen, fragt sich nur, wie das Management der defekten Blöcke darauf
> regiert. Eigentlich sollte das doch unbeeinträchtigt bleiben? Oder Müllt
> DOSen-Formatierung bzuw. "dd of=/dev/da0s1 ..." dem gleich die Tabellen
> weg?

Neh - das muss mit Spezialbefehlen passieren.
Die sind Standardisiert, aber ich weiß nicht welche Tools es dafür
gibt.
Hintergrund ist folgender (vereinfacht):
Beim schreiben braucht so ein Medium immer wieder einen Flash-Block,
den er sich aus dem Pool der bereits gelöschten Flash-Blöcke besorgt.
Der logische Block der gerade geschrieben wurde hat entweder vorher
keinen physikalischen Block gehabt, oder einen, der jetzt in den Pool
der ungelöschten freien wandert.
Wenn man ab und an einen Block schreibt ist die Welt in Ordnung,
weil das Medium in den Schreibpausen Blöcke durch löschen aus dem
ungelöschten freien Pool in den gelöschten Pool überführen.
Wenn man hingegen viel am Stück schreibt, dann gibt es schnell keine
gelöschten Flash-Blöcke mehr und der muss erst auf das löschen warten.
Wenn man viele logische Blöcke hat, die keinen physikalischen Block
zugeordnet haben gibt es mehr Blöcke in den Pools und der kann mehr
am Stück schreiben - als Nebeneffekt rotieren die auch alle mit und
sorgen für gleichmässigeren Verschleiß.
Wenn du so ein Medium voll schreibst belegt das Medium wenigstens so
viele physikalische Blöcke, wie das Medium logisch nach außen anbietet.
Das bleibt auch, wenn die Dateien gelöscht werden, weil nur dem
Filesystem bekannt ist, dass der Inhalt der Blöcke nicht mehr interessiert.
Unter FreeBSD gibt es neben read und write auch delete, aber ein delete
wird nicht mit jedem Filesystem gemacht und auch dieser Befehl bremst,
sodass man das nicht immer sinnvoll machen kann.
Zu dem Problem, das ein einmal gefülltes Medium die Pool bis zum
delete reduziert wandern auch noch Blöcke in die defekt-Liste, welche
dann nicht mehr im gelöschten-Pool zur Verfügung stehen.
Der Effekt, dass Blöcke zunehmend als defekt markiert werden wird auch
dadurch beschleunigt, dass man auf einem einmal voll geschriebenen
Medium nur noch Winzmengen schreibt, wie in deinem Fall, weil die
vom Filesystem ungenutzten Blöcke physikalische Blöcke zugewiesen haben,
die nicht mehr in der Rotation sind, d.h. der Verscheiß konzentriert sich
auf die wenigen verbliebenen.
Wenn du mit dd nullen schreibst wird einmal rotiert und du hast für den
Verschleiss etwas gutes getan, aber der Pool gelöschter bleibt klein.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message