Extremer Laufzeitunterschied beim Zählen/Aufsummieren von Dateien auf gleichen HDDs

Ist eigentlich auch ein Laufzeitunterschied wenn Du "rsnapshot du" auf die beiden Platten laufen lässt?
Daran hab ich bisher nicht gedacht. Schauen wir mal, es läuft gerade durch. Ich kann mir aber kaum eine Änderung des Verhaltens vorstellen, denn ob man du von Hand in der Shell ausführt, oder ob das ein Perl-Skript macht, dürfte keine Rolle spielen. Aber selbst wenn sich - aus welchen Gründen auch immer - ein Unterschied ergeben sollte, hilft mir das nichts. Das rsnapshot wird von einem Bash-Skript aus aufgerufen, das noch ein bissel Kram vorher und nachher erledigt, unter anderem eben zählen, Mail schicken, Zeit "stoppen", Sicherungs-/Rotierzeitpunkt vermerken usw.

MfG Dalai

--- Update ---

So, beide Platten haben gezählt. Die Platten wurden mittlerweile wieder zurückgetauscht, sdb ist also wieder sdb vom Anfang.
sdb
Code:
root@pluto:/# time rsnapshot -c /etc/rsnapshot/backup1.conf du
96G     /media/backup1/montag_dienstag.0/
7,5G    /media/backup1/montag_dienstag.1/
8,5G    /media/backup1/montag_dienstag.2/
7,3G    /media/backup1/montag_dienstag.3/
5,9G    /media/backup1/montag_dienstag.4/
5,5G    /media/backup1/montag_dienstag.5/
5,3G    /media/backup1/montag_dienstag.6/
7,2G    /media/backup1/montag_dienstag.7/
7,7G    /media/backup1/montag_dienstag.8/
8,5G    /media/backup1/montag_dienstag.9/
6,2G    /media/backup1/montag_dienstag.10/
9,1G    /media/backup1/montag_dienstag.11/
6,4G    /media/backup1/montag_dienstag.12/
13G     /media/backup1/monthly.0/
7,5G    /media/backup1/monthly.1/
7,7G    /media/backup1/monthly.2/
208G    insgesamt

real    21m43.263s
user    0m31.445s
sys     2m30.502s
sdc
Code:
root@pluto:/# time rsnapshot -c /etc/rsnapshot/backup2.conf du
96G     /media/backup2/donnerstag_freitag.0/
7,9G    /media/backup2/donnerstag_freitag.1/
7,5G    /media/backup2/donnerstag_freitag.2/
7,0G    /media/backup2/donnerstag_freitag.3/
7,4G    /media/backup2/donnerstag_freitag.4/
5,8G    /media/backup2/donnerstag_freitag.5/
5,2G    /media/backup2/donnerstag_freitag.6/
5,2G    /media/backup2/donnerstag_freitag.7/
8,7G    /media/backup2/donnerstag_freitag.8/
7,6G    /media/backup2/donnerstag_freitag.9/
7,1G    /media/backup2/donnerstag_freitag.10/
6,8G    /media/backup2/donnerstag_freitag.11/
8,7G    /media/backup2/monthly.0/
14G     /media/backup2/monthly.1/
8,0G    /media/backup2/monthly.2/
202G    insgesamt

real    29m19.020s
user    0m32.312s
sys     2m32.382s
Es ist also weiterhin ein Unterschied zwischen den Platten vorhanden, auch wenn der - vor allem prozentual - immer kleiner wird und mittlerweile mit dem leichten Geschwindigkeitsunterschied zwischen den Platten erklärt werden kann.

MfG Dalai
 
Aufgrund steigender Laufzeiten auf beiden Platten hab ich die Backup-Geschichte etwas umgestellt und verwende nun ein simples df zum Bestimmen des belegten Speicherplatzes. Das hat zwar den Nachteil, ungenauer zu sein, aber je einmal vor und nach dem Backup mehr als 20 Minuten Laufzeit von du sind einfach zu viel. Zumal das rsnapshot weiterhin unbekümmert in 13 Minuten durchgelaufen ist.

Also wenn du jetzt XFS im Einsatz hättest, würde ich dir dessen Quota-Subsystem dafür empfehlen. ;)
 
Davon abgesehen, dass Quoten auch mit ext3/4 funktionieren, was nützen mir die an der Stelle? Ich muss den insgesamt belegten Speicherplatz wissen, um errechnen zu können, wieviel Speicherplatz bei jedem rsnapshot-Durchlauf zusätzlich belegt wird, um eine ungefähre Prognose abgeben zu können, wie lange der verfügbare Plattenplatz reicht.

MfG Dalai
 
Davon abgesehen, dass Quoten auch mit ext3/4 funktionieren, was nützen mir die an der Stelle? Ich muss den insgesamt belegten Speicherplatz wissen, um errechnen zu können, wieviel Speicherplatz bei jedem rsnapshot-Durchlauf zusätzlich belegt wird, um eine ungefähre Prognose abgeben zu können, wie lange der verfügbare Plattenplatz reicht.

MfG Dalai
Genau das wird dir damit geboten. ;)

http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/ch08s03.html

Lies es mal durch, und probier es auch. Habs selber erst geglaubt, als ich es getestet hatte. Aber kurz darüber nachgedacht, macht das auch Sinn. Die Quotas müssen ja den verwendeten Platz berücksichtigen. Das geht halt auch global, und damit wird das extrem schnell.
 
Ja, ich kenne Quoten, auf den Servern benutzen wir die natürlich; auf dem NAS gibt's (bisher) keine Notwendigkeit dafür. Aber wie und womit sollte ich die globale Belegung ermitteln? Die Quote einzelner Nutzer bzw. Gruppen bekomme ich mit repquota, aber das gibt keine Infos zur gesamten Belegung. Auch bei quota, quotactl & Co sehe ich keine Option in die Richtung. Ich kenne auch nur usrquota und grpquota. Woran dachtest du genau?

MfG Dalai
 
Ja, ich kenne Quoten, auf den Servern benutzen wir die natürlich; auf dem NAS gibt's (bisher) keine Notwendigkeit dafür. Aber wie und womit sollte ich die globale Belegung ermitteln? Die Quote einzelner Nutzer bzw. Gruppen bekomme ich mit repquota, aber das gibt keine Infos zur gesamten Belegung. Auch bei quota, quotactl & Co sehe ich keine Option in die Richtung. Ich kenne auch nur usrquota und grpquota. Woran dachtest du genau?

MfG Dalai
Du hast nicht gelesen, was ich verlinkt habe, oder?

--- Update ---

http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/ch08s07.html

> sudo xfs_quota -xc 'report -h' /home
User quota on /home (/dev/hdb1)
Blocks
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 4.6G 0 0 00 [------]
testuser 103.4G 0 0 00 [------]
...

Damit bekommst du die Infos, die du haben willst. Musst es evtl. noch durch awk jagen. Ist aber immer noch um Größenordnungen schneller als du (und vor allem genauer).
 
Zuletzt bearbeitet:
Du hast nicht gelesen, was ich verlinkt habe, oder?
Doch natürlich. Und ich kenne die Tools zum Benutzen/Verwalten der Quoten ganz gut. Deswegen ja meine Frage.

> sudo xfs_quota -xc 'report -h' /home
User quota on /home (/dev/hdb1)
Blocks
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 4.6G 0 0 00 [------]
testuser 103.4G 0 0 00 [------]
...

Damit bekommst du die Infos, die du haben willst. Musst es evtl. noch durch awk jagen. Ist aber immer noch um Größenordnungen schneller als du (und vor allem genauer).
Ja, mit repquota gibt's eine solche Liste auch. Also müsste ich für jeden Nutzer eine Quote einrichten, und diese auch noch mit dem Server synchron halten. Außerdem müsste ich alle Quoten zusammenrechnen, und bekomme diese trotzdem nur in KiB. Dann kann ich auch bei df -k /mnt/point bleiben, was nochmal schneller ist und weniger Aufwand macht (bei selber Genauigkeit). Übrigens ist du genauer als df oder die Quoten, denn du kann Byte-Auflösung, die anderen nur KiB.

MfG Dalai
 
Sollte auch global gehen, sonst hätte ich das ja nicht vorgeschlagen Hab hier kein XFS mehr im Einsatz, sonst hätte ich ein praktisches Beispiel angeboten. Muss das nochmal zusammen suchen.
 
Naja, wichtig wäre, dass es bei ext(4) global geht, denn das Dateisystem stelle ich mit Sicherheit nicht deswegen um ;). Aber trotzdem: es bringt ja nix, wenn ich alle für Nutzer erst Quoten anlegen und die synchron halten muss.

MfG Dalai
 
Zuletzt bearbeitet:
Ich stellte gerade fest, dass ein Anlegen und Synchronisieren der Quoten gar nicht notwendig ist, denn das wären nur die Limits, um die es gar nicht geht. Es reicht ja das Reporting, das auch ohne Limits funktioniert. Es bleibt dennoch der höhere Aufwand des Aktivierens und des Zusammenrechnens der Quoten. Bzw. für den Fall, dass sich ein globaler Wert (Summe der Quoten) findet, ist der wahrscheinlich auch nicht genauer als die Angabe von df.

MfG Dalai
 
Zurück
Oben Unten