Re: dpkg --get-selections
Am Donnerstag, 22. März 2012 schrieb Dietrich Clauss:
> > Es gibt nur wenige Verzeichnis, die ich weglasse:
> >
> >
> > merkaba:~/backup> cat debian-exclude
> > /proc/**
> > /sys/**
> > /tmp/**
> > /var/cache/apt/archives/*.deb
> > /var/tmp/**
>
> /var/cache/* kann man komplett weglassen. Der FHS meint[1] hierzu:
> | The application must always be able to recover from manual deletion
> | of these files (generally because of a disk space shortage).
>
> Wenn auf dem Rechner sowas wie approx oder squid läuft, sammeln sich
> dort gern ganz ordentliche Datenmengen an. Sollte ein Paket mit dem
> Verschwinden dieser Daten nicht klarkommen, ist das einen Bugreport
> wert. Ab squeeze hatte ich damit aber noch nie Probleme.
Hmmm, stimmt auch wieder. Allerdings verliere ich damit evtl. Caches, die
evtl. erst wieder neu aufgebaut werden müssten - einmal installierte
Pakete brauche ich aber in der Regel wirklich nicht mehr. Mit diesem
ThinkPad T520 und Intel SSD 320 ist mein Verlangen nach Optimierungen
derzeit aber auch begrenzt. In Zusammenhang mit der 2 TB-Hitachi-Platte
via eSATA rennt rsync innerhalb von weniger als 10 Minuten durch das
Backup und sichert dabei gleich noch meinen virtuellen Server mit, der
unter anderem lichtvoll.de hostet sowie das Debian auf dem USB-Stick am
ASUS WL500g Premium. Inkrementiell. Aber selbst Initial war in einer
Stunde alles erledigt. Und dass mit ca. 210 GB. Laut vmstat bretterte
Linux beim initialen Backup weitgehend sequentiell auf die Platte. Ext4-
Dateisystem dort. So wie das aus sah, hat Linux ordentlich gesammelt,
umsortiert und dann möglichst sequentiell geschrieben. Das stimmte auch
mit nur wenig hörbaren Seek-Bewegungen überein.
> Bei /var/tmp formuliert der FHS eher vage:
> | The /var/tmp directory is made available for programs that require
> | temporary files or directories that are preserved between system
> | reboots. Therefore, data stored in /var/tmp is more persistent than
> | data in /tmp.
> |
> |
> |
> | Files and directories located in /var/tmp must not be deleted when
> | the system is booted. Although data stored in /var/tmp is typically
> | deleted in a site-specific manner, it is recommended that deletions
> | occur at a less frequent interval than /tmp.
>
> Mh, muß man das nun mit sichern oder nicht? Ich nehme es meistens mit
> rein, aber nicht immer; je nachdem, wie genau das Backup werden soll.
Also damit hatte ich bislang kein Problem:
merkaba:~> du -sch /var/tmp/*
11M /var/tmp/kdecache-kdm
656M /var/tmp/kdecache-martin
192M /var/tmp/kdecache-ms
857M insgesamt
Ich denke, das Haupt-Argument ist auch hier wieder der erneute Aufbau.
Die kdecache-Verzeichnisse lassen sich jedenfalls löschen. KDE baut sie
dann wieder auf. Das merke ich aber bei Festplatten-basierten Systemen
ganz besonders an der längeren Zeit, von der Anmeldung bis der KDE-Desktop
erscheint.
Also insofern könnte ich /var/cache/** auch weglassen, klar. Allerdings
könnte da dann etwas dabei sein, was erneuten Netzwerk-Traffic benötigt.
Aber auch das ist bei kdecache ebenfalls der Fall:
merkaba:~> du -h /var/tmp/kdecache-martin/http
56M /var/tmp/kdecache-martin/http
(Browser-Cache)
Also gut, wahrscheinlich stelle ich das Exclude mal auf /var/cache/** um.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: