Hallo,
gestern haben wir über die 2G Grenze beim Erstellen einer Backupdatei gesprochen. Habe mich ein wenig umgeschaut und bin auf eine Mail gestoßen in der die Schuld der glibc zugeschoben wird. Scheinbar ist es nicht ein Problem vom Filesystem. Siehe: http://radawana.cg.tuwien.ac.at/mail-archives/lll/200006/msg00125.html
Daraus schließe ich, dass das Problem noch länger existieren wird und wir lernen sollten, einfach damit zurechtzukommen.
Also bin ich gerade dabei einen Testlauf des beschriebenen Kommandos auf meinen Schläppi durchzuführen.
Ich habe es ein wenig verändert: [inspiron]pazzo$ tar -czvp --one-file-system --exclude RH_72 -f - . | split -b 1000m - `hostname -s`_`whoami`_`date +"%Y-%m-%d"`.tar.gz.
Die Option one-file-system benutze ich in der Hoffnung, dass evtl. gemountete Verzecihnisse nicht mitgesichert werden. Ich habe nämlich in meiner home mehrere Verzeichnisse mit Samba mounts.
Weiters habe ich auch die ISOs der RedHat unter dem Verzeichnis RH_72 kopiert, sodass ich die CDs nicht andauernd mitschleppen und wechseln muss. Mittels der Option --exclude RH_72 befehle ich dem tar-Tool das Verzeichnis zu überspringen.
-f - sagt dem tar-Tool, dass das Ergebnis auf den "standard output" Kanal geschrieben werden soll, sodass es mittels Pipe '|' dem split-Tool übergeben werden kann.
Mittels split wird dann das Archiv in meherere 1G Teile aufgesplittet. Als Eingang für split wird wieder - angegeben, sodass split die Daten vom "standard input" einliest und als letzter Parameter gebe ich das Filenamenprefix an, welches ich dynamisch zusammenstelle:
`hostname -s`_`whoami`_`date +"%Y-%m-%d"`.tar.gz.
das wird dann in meinen Fall
inspiron_pazzo_2002_05_24.tar.gz.
Und die Dateien werden dann von split folgendermaßen benannt:
inspiron_pazzo_2002_05_24.tar.gz.aa inspiron_pazzo_2002_05_24.tar.gz.ab ...
Kleiner Tipp, mittels folgendem Kommando kann man sehr einfach die tar-Dateien im aktuellen Verzeichnis in einem 3-Sekunden-Rhythmus überwachen:
[inspiron]pazzo$ while true; do clear ; ls -ld *tar* ; sleep 3 ; done
Hehe es scheint zu funktionieren: -rw-rw-r-- 1 pazzo pazzo 1000M Mai 24 15:23 inspiron_pazzo_2002-05-24.tar.gz.aa -rw-rw-r-- 1 pazzo pazzo 230M Mai 24 15:24 inspiron_pazzo_2002-05-24.tar.gz.ab
mfg. Patrick
Hi,
ich kommentiere nur einen kleinen Teil der mail.
Kleiner Tipp, mittels folgendem Kommando kann man sehr einfach die tar-Dateien im aktuellen Verzeichnis in einem 3-Sekunden-Rhythmus überwachen:
[inspiron]pazzo$ while true; do clear ; ls -ld *tar* ; sleep 3 ; done
Hierfuer gibt es auch den Befehl "watch", den viele nicht kennen und den ich deswegen erwaehnen moechte.
watch "du -k *tar*"
wuerde in etwa dasselbe erledingen. Siehe man watch.
Bye, Chris.
gestern haben wir über die 2G Grenze beim Erstellen einer Backupdatei gesprochen. Habe mich ein wenig umgeschaut und bin auf eine Mail gestoßen in der die Schuld der glibc zugeschoben wird. Scheinbar ist es nicht ein Problem vom Filesystem. Siehe: http://radawana.cg.tuwien.ac.at/mail-archives/lll/200006/msg00125.html
Daraus schließe ich, dass das Problem noch länger existieren wird und wir lernen sollten, einfach damit zurechtzukommen.
Stimmt nicht.
Ich habe ein System mit einem Vanilla 2.4.5 Kernel (+ 1 Reiser FS patch) - also nicht gerade der allerletzte Schrei - auf dem ich mit Reiserfs problemlos dies machen kann:
chris@linuxbox:~$ dd if=/dev/zero of=bigfile bs=1024 count=2300000 2300000+0 records in 2300000+0 records out chris@linuxbox:~$ ls -la bigfile -rw-r--r-- 1 chris users 2355200000 May 24 21:57 bigfile
Ich meine, dass Linux seid 2.4.0 64 bit filepointer verwenden kann. Von der glibc und von gcc sollte es auch keine Probleme geben, der Typ "long" ist da ja schon seit jeher 64 bit.
Ich wuerde mal sagen, seid 1.5 Jahren oder so liegt der schwarze Peter wirklich nur mehr bei ext2fs.
+++
Deine tar Tipps sind aber unabhaengig davon auf jeden Fall praktisch!
Bye, Chris.
* chrism@desk.nl (chrism@desk.nl) wrote:
Ich meine, dass Linux seid 2.4.0 64 bit filepointer verwenden kann. Von der glibc und von gcc sollte es auch keine Probleme geben, der Typ "long" ist da ja schon seit jeher 64 bit.
Ich wuerde mal sagen, seid 1.5 Jahren oder so liegt der schwarze Peter wirklich nur mehr bei ext2fs.
erm...
http://www.suse.de/~aj/linux_lfs.html
Leider wegen ein paar signed/unsigned probleme in manche low-level storage treiber ist der limit auf diese geraete noch 1Tb und nich 2Tb wie man sich erwartet.
Ja kannst du dies auch mit tar machen? Denn wenn tar auf die glibc aufbaut und nicht die erweiterten API calls verwendet, sollte das Problem auch auf Reiser FS weiterhin bestehen. Ich kann dies hier nicht testen, leider nur ext2 :)
mfg. Patrick
chrism@desk.nl wrote:
gestern haben wir über die 2G Grenze beim Erstellen einer Backupdatei gesprochen. Habe mich ein wenig umgeschaut und bin auf eine Mail gestoßen in der die Schuld der glibc zugeschoben wird. Scheinbar ist es nicht ein Problem vom Filesystem. Siehe: http://radawana.cg.tuwien.ac.at/mail-archives/lll/200006/msg00125.html
Daraus schließe ich, dass das Problem noch länger existieren wird und wir lernen sollten, einfach damit zurechtzukommen.
Stimmt nicht.
Ich habe ein System mit einem Vanilla 2.4.5 Kernel (+ 1 Reiser FS patch) - also nicht gerade der allerletzte Schrei - auf dem ich mit Reiserfs problemlos dies machen kann:
chris@linuxbox:~$ dd if=/dev/zero of=bigfile bs=1024 count=2300000 2300000+0 records in 2300000+0 records out chris@linuxbox:~$ ls -la bigfile -rw-r--r-- 1 chris users 2355200000 May 24 21:57 bigfile
Ich meine, dass Linux seid 2.4.0 64 bit filepointer verwenden kann. Von der glibc und von gcc sollte es auch keine Probleme geben, der Typ "long" ist da ja schon seit jeher 64 bit.
Ich wuerde mal sagen, seid 1.5 Jahren oder so liegt der schwarze Peter wirklich nur mehr bei ext2fs.
+++
Deine tar Tipps sind aber unabhaengig davon auf jeden Fall praktisch!
Bye, Chris.
https://secure.pcnotruf.net/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
To: lugbz-list@lugbz.org
erm...
Ok, ok. Es sind also noch nicht alle Felle im Trockenen bezueglich grosser Files. Das wusste ich nicht.
Trotzdem: mit ReiserFS unter meinem 2.4.5er vanilla kernel (+1 ReiserFS patch) von vor beinahe einem Jahr scheine ich keine Probleme mit Files groesser als 2GB zu haben. Auch nicht mit tar:
$ dd if=/dev/zero of=bigfile1 bs=1024 count=1500000 1500000+0 records in 1500000+0 records out
$ dd if=/dev/zero of=bigfile2 bs=1024 count=800000 800000+0 records in 800000+0 records out
$ tar cf ~/big.tar bigfile1 bigfile2
$ ls -la ~/big.tar -rw-r--r-- 1 chris users 2355210240 May 25 18:45 /home/chris/big.tar
$ od --skip-bytes=2355210000 ~/big.tar 21430323420 000000 000000 000000 000000 000000 000000 000000 000000 * 21430324000
+++
OK, an dieser Stelle wollte ich also die Schuld wieder ext2fs in die Schuhe schieben. Aber kurz vor dem Abschicken der Mail habe ich dann doch dasselbe auf ext2fs probieren wollen um zum Beweis die Fehlermeldung mitzuliefern :)
$ dd if=/dev/zero of=bigfile1 bs=1024 count=1500000 1500000+0 records in 1500000+0 records out
$ dd if=/dev/zero of=bigfile2 bs=1024 count=800000 800000+0 records in 800000+0 records out
$ tar cf /home2/Chris/big.tar bigfile1 bigfile2
$ ls -la /home2/Chris/big.tar -rw-r--r-- 1 chris users 2355210240 May 25 19:09 /home2/Chris/big.tar
$ od --skip-bytes=2355210000 /home2/Chris/big.tar 21430323420 000000 000000 000000 000000 000000 000000 000000 000000 * 21430324000
Geht also auch mit ext2fs!?
Des Raetsels Loesung fand ich dann im Changelog meiner Linux Distribution: Slackware unterstuetzt Files groesser als 2 GB schon seit einem Jahr und zwar mit ReiserFS _und_ ext2fs.
Ob sich da Red Hat was abschauen koennte ;-)
Bye, Chris.
Hi.
Ja kannst du dies auch mit tar machen? Denn wenn tar auf die glibc aufbaut und nicht die erweiterten API calls verwendet, sollte das Problem auch auf Reiser FS weiterhin bestehen. Ich kann dies hier nicht testen, leider nur ext2 :)
Ja (siehe Antwort auf Micheles Mail).
bye, Chris.
Geht also auch mit ext2fs!?
Yepp.
Des Raetsels Loesung fand ich dann im Changelog meiner Linux Distribution: Slackware unterstuetzt Files groesser als 2 GB schon seit einem Jahr und zwar mit ReiserFS _und_ ext2fs.
Ob sich da Red Hat was abschauen koennte ;-)
Funkt seit RH7.1 ganz ohne Probleme [mach mir 4Gb ISO images seit APR 2001 mindestens]
Ciao, Michele
Ob sich da Red Hat was abschauen koennte ;-)
Funkt seit RH7.1 ganz ohne Probleme [mach mir 4Gb ISO images seit APR 2001 mindestens]
Hmmm... Ok.
Aber warum hatte Patrick dann die Probleme? Verwendet er eine aeltere Version oder hat er uns den tar/split Trick nur zum Spass verraten? Patrick: RFC!
Bye, Chris.
Ich habe die Probleme ja gar nicht gehabt, Raphael hatte sie. Und da ich immer alles glaube, dachte ich es wäre unter ext2 nicht möglich Dateien dieser Größe anzulegen. Muss in Zukunft weniger auf euch losen, speziell wenns Donnerstag Abend gegen Ende vom Treffen ist ;)
Mir ging's genau gleich! Wir haben also ein Problem geloest, das wir gar nicht haben ;-)
Ich hoffe der Tipp ist trotzdem nützlich, man kann damit ja auch einfach Dateien auf die Größe von "Removable medias" (CD-Roms, Disketten, ...) aufsplitten und dann wieder zusammenfügen.
Stimmt!
Bye, Chris.
Patrick Ohnewein wrote:
Karl qualche settimana fa ha portato il modulo alla riunione, dando così la possibilità ai presenti di firmare.
Non so se è già stato spedito, magari potremmo portarlo anche questo giovedì.
Non ho ancora spedito niente e posso portare i module
Ciao Karl -- 01.06. - Tag der offenen Tuer an der GOB und LIH 08.06. - Eternity of Rock Openair - Infos: http://eternity.isch.org 15.06. - LUGBZ-Workshop: Web development with PHP .-. /v\ L I N U X // \ >Phear the Penguin< /( )\ ^^-^^ karl@lunger.org
Ich habe die Probleme ja gar nicht gehabt, Raphael hatte sie. Und da ich immer alles glaube, dachte ich es wäre unter ext2 nicht möglich Dateien dieser Größe anzulegen. Muss in Zukunft weniger auf euch losen, speziell wenns Donnerstag Abend gegen Ende vom Treffen ist ;)
Wenn ich mich richtig erinnere, hat Raphael das Problem auf einem Samba Mount gehabt, also war es eine Windows-Partition. Es wäre ganz interessant herauszufinden ob diese Einschränkung nur bei FAT oder auch bei NTFS gelten.
Ich hoffe der Tipp ist trotzdem nützlich, man kann damit ja auch einfach Dateien auf die Größe von "Removable medias" (CD-Roms, Disketten, ...) aufsplitten und dann wieder zusammenfügen.
mfg. Patrick
chrism@desk.nl wrote:
Ob sich da Red Hat was abschauen koennte ;-)
Funkt seit RH7.1 ganz ohne Probleme [mach mir 4Gb ISO images seit APR 2001 mindestens]
Hmmm... Ok.
Aber warum hatte Patrick dann die Probleme? Verwendet er eine aeltere Version oder hat er uns den tar/split Trick nur zum Spass verraten? Patrick: RFC!
Bye, Chris.
https://secure.pcnotruf.net/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
To: lugbz-list@lugbz.org
Karl qualche settimana fa ha portato il modulo alla riunione, dando così la possibilità ai presenti di firmare.
Non so se è già stato spedito, magari potremmo portarlo anche questo giovedì.
byez Patrick
weiss@ndreas.it wrote:
http://www.freego.it/news.php?show=411
https://secure.pcnotruf.net/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
To: lugbz-list@lugbz.org
Ich habe die Probleme ja gar nicht gehabt, Raphael hatte sie. Und da
ich
immer alles glaube, dachte ich es wäre unter ext2 nicht möglich
Dateien
dieser Größe anzulegen. Muss in Zukunft weniger auf euch losen,
speziell
wenns Donnerstag Abend gegen Ende vom Treffen ist ;)
Ich weiß nicht wie wir auf ext2 gekommen sind. Ich glaube ich habe immer von dem gemountetem SMB share gesprochen.
Wenn ich mich richtig erinnere, hat Raphael das Problem auf einem Samba Mount gehabt, also war es eine Windows-Partition. Es wäre ganz interessant herauszufinden ob diese Einschränkung nur bei FAT oder auch bei NTFS gelten.
Ja, stimmt. Ich glaube es ist ein Windows 2000 server von dem ich einen share mounte. Bei 2GB geht gzip (von "tar czf ...") auf 100% CPU und der Prozess wird nicht mehr beendet.
Ich hoffe der Tipp ist trotzdem nützlich, man kann damit ja auch einfach Dateien auf die Größe von "Removable medias" (CD-Roms, Disketten, ...) aufsplitten und dann wieder zusammenfügen.
Ja, war nützlich, nun funktioniert alles paletti :)
bye, raf
hallo,
nachdem lugbz PHP-Nuke auf seiner homepage laufen hat, kann mir vielleicht jemand helfen. ich habe interessehalber PHP-Nuke auf meinem pc installiert, die installation wird einem ja wirklich leicht gemacht. es läuft soweit auch gut, nur gibt es ein problem beim user-login. user werden nicht gefunden, es gibt immer die meldung "incorrect login". als administrator kann ich mich aber ohne probleme einloggen. woran kann das liegen? verwende: - mandrake 8.2 - php-nuke 5.3 - mysql 3.23 - php-mysql 4.1.2
danke für eventuelle hilfe! lg, andreas
Hi,
da wird Dir Raphael vermutlich helfen koennen.
Ich geb' Dir inzwischen den Rat, PHP-Nuke *nicht* auf einem oeffentlich zugaengliche Webserver zu legen. Das System ist naemlich loechrig wie ein Sieb und wird gern von Script kiddies auseinandergenommen (wie wir leider auf der Lugbz Seite gesehen haben :-(
Bye, Chris.
chrism@desk.nl wrote:
Hi,
da wird Dir Raphael vermutlich helfen koennen.
Ich geb' Dir inzwischen den Rat, PHP-Nuke *nicht* auf einem oeffentlich zugaengliche Webserver zu legen. Das System ist naemlich loechrig wie ein Sieb und wird gern von Script kiddies auseinandergenommen (wie wir leider auf der Lugbz Seite gesehen haben :-(
Bye, Chris
danke für den hinweis! werde den webserver inzwischen 'mal schnellstens öffentlich unzugänglich machen ... was ist daran eigentlich so löcherig? lg, andreas
danke für den hinweis! werde den webserver inzwischen 'mal schnellstens öffentlich unzugänglich machen ... was ist daran eigentlich so löcherig?
Zumindest bei unserer Version, 5.3.1, gibt es zahlreiche Sicherheitsloecher. ich sah, dass Du 5.3 benutzt, also sind die bei Deiner Version vermutlich auch noch drinnen.
So z.B. eine Stelle im code, wo externe Files ueber eine Variable $file ge-include-iert werden, die nicht weiter ueberprueft wird. Wenn das nicht gepatcht ist, kann ein request wie index.php?file=/some/interesting/file/on/server interessante Einsichten liefern...
Der eingebaute Filemanager hat auch Probleme: es ist relativ leicht die Sicherung zu umgehen, die ihn nur fuer Admins zugaenglich macht (ich sag' jetzt mal nicht wie, aber die Interessierten koennen leicht selbst draufkommen :)
Bye, Chris.
PS: Raphael sei Dank sind diese Loecher in unserer Version jetzt gepatcht!
-
Andreas Weiss -
chrism＠Desk.nl -
Karl Lunger -
Michele Baldessari -
Patrick Ohnewein -
Raphael Vallazza