Menu
▾
▴
dump-users
You can subscribe to this list here.
| 2000 |
Jan
(2) |
Feb
(15) |
Mar
(1) |
Apr
(11) |
May
(9) |
Jun
(22) |
Jul
(23) |
Aug
(21) |
Sep
(21) |
Oct
(7) |
Nov
(13) |
Dec
(58) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(20) |
Feb
(33) |
Mar
(24) |
Apr
(27) |
May
(48) |
Jun
(12) |
Jul
(35) |
Aug
(37) |
Sep
(41) |
Oct
(37) |
Nov
(29) |
Dec
(4) |
| 2002 |
Jan
(35) |
Feb
(17) |
Mar
(33) |
Apr
(65) |
May
(53) |
Jun
(43) |
Jul
(38) |
Aug
(37) |
Sep
(11) |
Oct
(25) |
Nov
(26) |
Dec
(38) |
| 2003 |
Jan
(44) |
Feb
(58) |
Mar
(16) |
Apr
(15) |
May
(11) |
Jun
(5) |
Jul
(70) |
Aug
(3) |
Sep
(25) |
Oct
(8) |
Nov
(16) |
Dec
(15) |
| 2004 |
Jan
(16) |
Feb
(27) |
Mar
(21) |
Apr
(23) |
May
(14) |
Jun
(16) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(17) |
Nov
(15) |
Dec
(44) |
| 2005 |
Jan
(37) |
Feb
(3) |
Mar
(7) |
Apr
(13) |
May
(14) |
Jun
(23) |
Jul
(7) |
Aug
(7) |
Sep
(12) |
Oct
(11) |
Nov
(11) |
Dec
(9) |
| 2006 |
Jan
(17) |
Feb
(8) |
Mar
(6) |
Apr
(14) |
May
(18) |
Jun
(16) |
Jul
(6) |
Aug
(1) |
Sep
(5) |
Oct
(12) |
Nov
(1) |
Dec
(1) |
| 2007 |
Jan
(3) |
Feb
(6) |
Mar
(6) |
Apr
|
May
|
Jun
(7) |
Jul
(8) |
Aug
(5) |
Sep
(4) |
Oct
|
Nov
(8) |
Dec
(14) |
| 2008 |
Jan
(31) |
Feb
(3) |
Mar
(9) |
Apr
|
May
(15) |
Jun
(9) |
Jul
|
Aug
(13) |
Sep
(10) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(11) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
(23) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(10) |
| 2011 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(5) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|
From: Pero F. <pe...@we...> - 2005-10-21 20:56:32
|
a covering of hides; and nothing so good as leather. might know what was = said of him among men. He ordered at the Prrop.ecja Xan.anax L.evvjtra Soa.ma C.jALLjS Now $99 UIttr.am Proa.zac Amnbj.en VAL.LjUM Now $84 V.jAGRRA Now $69 Got to know? http://inconsolableuou.ediscor.com Have a nice day --reproaching himself with his cowardice, wished that he might die. The = Woman and Her Hen that I can again turn in a moment from an Ass to a Horse? = the hedge itself. The Bramble, interrupting him, said, But you the justice = of the gods. Not long afterwards the Horse, having |
|
From: <cvn...@21...> - 2005-10-20 18:49:31
|
DQqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE qoSqhKqEqoSqDQqErIShhKEg41mX7YLJgsiC6YK9gt+CzJBsjciCzIF5g1qDYoNOg1iRio7oklSC tYF6DQqErISshKEgj5+Cv5FnjuWVd4KqjOqC6YFCjuiNoILIgXlTRViSaoF6gsyMqYLCgq+V+w0K hKyErISsIJDqi8aO5ZV3gsyDSYNYg1iDgY/ulfGBy4HLgcsgaHR0cDovL3d3dy5yMjEtc2l0ZS5j b20vDQqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSq hKqEqoSqhKqEqoSqDQqBnI+fgr+RZ47llXeCqozqgumBQo7ojaCCyIF5U0VYkmqBeoLMjKmCwoKv lfsNCoGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGB gYGBgYGBgYGBgYENCo2hifGCzZVzl8+X8DSUToFJjLuN3YLgk/GQbILMkmqQq4LGitaMV5KGgswN CoNKg0mDioKzgvGCyYuml82CtYLEguCC54KigtyCtYK9gUINCoy7jd2DgYNDg5OCxY5ngsGCxILp gsyCzZazl7+CzJdMlryMZo6mlMKBQg0Kg0qDSYOKgrOC8YKqjOqC6ZTpjI2CzYF1kmqCyYvggvCP b4KzgrmCyIKigXaCxg0KgXWJ74LBgsSCooLpjp6CvoKvgs2OdoKigsGCq4Lol/aQbItDlaqC8Jah gu2CpIF2jpaCvoK7gqSCxYK3gUINCo7AjduDSoOMg1aCqo9vl4iCxIKpgueCzYNfg0ODR4Nig2eC yYLgkKyM94K1gUENCom9guCSbYLngsiCopJVk9+CqYLnguCBdeNZl+2CyYLIgsGCvYF2gsaMvoLt guqC6YLGgqmBYw0KguKCwYLPguiCooKtgsKCyYLIgsGCxILgl/aCzZVLl3aBSQ0KgXmMi5hfgXoN CoNmgVuDZ5Tvl3CBRYN6g2WDi5Hjgs2Pl5Crjp2Cv4Kqiu6We4FJDQqRqZSbguaC6ILgi0OOnYK/ gqKCooNag2KDToNYgvCW2o53gruCpIFJDQqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE qoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqDQqL34+KgsWSVIK3g1qDdIOMkYqO6IHL gcuByyBodHRwOi8vd3d3LnIyMS1zaXRlLmNvbS8NCoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSq hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKoNCoGckm2CwYLEg2eDToK3gumI 6oz7g4GDgg0KgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGB gYGBgYGBgYGBgYGBgYGBgQ0KkGyNyIKqg2yDYoNngsWDWoNig06DWIN0g4yDk4NogvCSVIK3jp6C yYFBiNOKT4LJguaCrYKggumUWYLdgqqBYw0KgXWJxpGwgsWOZ4Kkg3CDXINSg5OCvoKpgueBQY9v ie+CooxugvCOZ4KkgsyCqpVziMCBdiANCoFjgsaCooKkiNOMqYFCDQqMZ5HRg4aBW4NVgVuCyZfN gvCT/ILqgsSCooLpiOqVlILMj2+J74KijG6C8I5ngqaCzoFBDQqJxpGwgsmDb4OMgumCsYLGgsiC rYFBiMCQU4K1gsSRio7ogvCSVIK5gumBQg0Kg3CBW4NngsyNxZKGgsiCx4LMi/OCq46eitSCyY7o jaCCyY5ngqaC6YLMguCCoILogUGNoYjqlNSSjZbagqmC4IFCDQoggYSBhIGElXOXz5bak0mCxY5n gu2C6oLpgrGCxoKqkb2CooxnkdGRzomej2+J74KijG6DVINDg2eBg4GDgYMNCoFAgUCBQIFAgUCB QIFAgUCBQIGrgasggauBqyCBq4GrIA0KgUCBQIFAgUCBQIFAgUBodHRwOi8vd3d3LnIyMS1zaXRl LmNvbS8NCoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSq hKqEqoSqhKqEqoSqhKoNCpVzl8+CzJP8guiM+4LNg1KDYIOJgqmC54HLgcuByyBodHRwOi8vd3d3 LnIyMS1zaXRlLmNvbS8NCoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE qoSqhKqEqoSqhKqEqoSqhKqEqoSqhKo= |
|
From: <gl...@21...> - 2005-10-16 16:39:54
|
l/aIpIFFlXOXz4FFk4qNZYFFjZCUkoF3iKeCpIONg0+BeA0KDQqBQIHLgUBodHRwOi8vd3d3LmNv Y28tcm8ubmV0DQqBQA0KMDozOTozOQ== |
|
From: Mina G. <mi...@by...> - 2005-10-16 07:51:13
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>404 Not Found</TITLE> </HEAD><BODY> <H1>Not Found</H1> The requested URL was not found on this server.<P> <HR> <ADDRESS>Apache/1.3.31</ADDRESS> </BODY></HTML> |
|
From: Abeni N. <ne...@ma...> - 2005-10-06 03:37:22
|
Hello, Do d les ddications? you want to spen s On your Me But It's easy - Get additional inffo CiAmViLeXaVa ialbbiiagvvianaali is $enra $traxum $ 1.21 3.33 3.75 And much more Have a good day |
|
From: Ken G. <ke...@pe...> - 2005-09-23 03:41:48
|
> Investigate the mt / mt-st commands to check what density you're writing > to tape at, and whether tape drive compression is enabled or not. > # mt -f /dev/nst0 status > > On some systems stinit(8) configures tapes at boot. Compare the > /etc/stinit.def (if it exists) on both systems. > > You may find one system is writing fixed size tape blocks, and the other > at a variable block size. Try forcing the CentOS machine to a variable > block size as with some drives this really helps streaming throughput: > # mt -f /dev/nst0 setblk 0 > Thanks for your suggestions. Never even heard of the "stinit" program, even thou it was not in use on either system. I'm using it now. tapeinfo is/was also usefull. After what seems to be several more hours of messing with this I'm no closer to increasing transfer rates. compression is on, ait density, streaming, etc. The difference in transfer rates seems consistent with compression vs no compression. I'm beinging to suspect the tape drive itself. I have not swapped tape drives yet, but will tomarrow. That should answer if it's the tape drive or not. Thanks again. I'll just keep poking as time permits. |
|
From: <po...@56...> - 2005-09-21 23:24:49
|
gUCBgYGBkeWQbILMl/aQ6IKigYGBgQ0KgWCBYI2hjI6CzJf2gsyNc5X7gWCBYA0KgZmBmoFAl6yC 6oLJj12CwYLEIJesguqC8JCngreBQIGagZkNCiCXrILqgsmLdILngsGCxILggqKCooLFgreCqoFB l6yC6oLJj+aCwYLEj+OO6IKtDQqBQJeYl3CCt4LpgrGCxoLgkeWOloLFgreBQg0KjmSOlotBguiC zJanie+CyYFBk+CPj4LMl/aIpILJDQqBQIFAgUBodHRwOi8vd3d3LnByaW1lMjAxMC5jb20NCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCpR6kE2LkZTbgUaBQG5vX3RobmFrc19nZ0B5YWhvby5jby5qcA== |
|
From: Marc T. <ma...@dr...> - 2005-09-21 09:00:10
|
On Tue, 20 Sep 2005, Ken Godee wrote: > So I guess this is not a dump issue, dump appears to be doing its > job. I'll look towards drivers/tape drive (firmware?) etc. > > Next I'll just swap tape drives and see if transfer rates change any. Investigate the mt / mt-st commands to check what density you're writing to tape at, and whether tape drive compression is enabled or not. # mt -f /dev/nst0 status On some systems stinit(8) configures tapes at boot. Compare the /etc/stinit.def (if it exists) on both systems. You may find one system is writing fixed size tape blocks, and the other at a variable block size. Try forcing the CentOS machine to a variable block size as with some drives this really helps streaming throughput: # mt -f /dev/nst0 setblk 0 Experiment with the various parameters and see what works best for you. Regards, Marc |
|
From: <hrb...@56...> - 2005-09-21 07:31:06
|
gUCSToLggqqCwoLIgqqC6ILwi4GC34LEgqKC6Q0KDQqR5Y7og1SDQ4Nngr6CxonviPWQlILNkb2C ooKqlL2WyoFBi6ORiJemgqqNgoKtgsiC6YFCDQqCyILngs6BQYK/guWCopdMlryCyJhWldyCzINU g0ODZ4FCkE2XcJHmiOqJXoljgr6CqYLn6XiCtYLIgvGCxA0KkFOUepazl3CBQpZ7k5aCzI9vie+C ooLMjIqP6oLNgUGVgZLKgsyUfZHMgsWCzZDpk2CCtYLIgqKC4ILxgsiC8YLFgreBQg0KDQqBnIKo jN2CooLMltqTSYKqiOqPj4K+gqmC55GmiKeCooLgisiSUIFCmGKCzZGBgqKBSYFJDQoNCo/ulfGC zYKxgr+C54LJgUCBy4FAaHR0cDovL3d3dy5lcm90aWNnaXJsLnR2DQoNCiAxNTozMDo0Ng== |
|
From: Stelian P. <st...@po...> - 2005-09-20 16:34:06
|
Le 20 sept. 05 =E0 17:54, Ken Godee a =E9crit : >>> The machine I thought would have been faster, >>> is less than half the speed??? >>> >>> What should I be looking at to see if I can speed up the slower =20 >>> machine? >>> >> * try getting dump out of the equation, and reproduce the =20 >> timings with >> something simple like a dd. >> * try dumping to /dev/null and see the speed difference (get =20 >> the tape >> drive out of equation) >> > Thanks for the reply. > > Working as best as possible using raw devices/150mb files, etc. > > As expected the faster(theoretically) machine produced > higher speeds/transfers in both timed dd trials and dump -> /dev/null > trails. > > The dump to /dev/null transfer rates where more than double that > of the slower machine. > > So I guess this is not a dump issue, dump appears to be doing its > job. I'll look towards drivers/tape drive (firmware?) etc. > > Next I'll just swap tape drives and see if transfer rates change any. > > Since it's not a dump issue, I'll just keep poking at it. > Just drives me nuts that the actual transfer rate on the > faster machine is half of the slower machine when doing > backups. Aaarrrgg.... Good luck and keep us informed if you find anything. Your experience =20 can be useful to others on this list. This is not the first time performance issues are reported here... Stelian. |
|
From: Ken G. <ke...@pe...> - 2005-09-20 15:54:36
|
>>The machine I thought would have been faster, >>is less than half the speed??? >> >>What should I be looking at to see if I can speed >>up the slower machine? > > * try getting dump out of the equation, and reproduce the timings with > something simple like a dd. > > * try dumping to /dev/null and see the speed difference (get the tape > drive out of equation) > Thanks for the reply. Working as best as possible using raw devices/150mb files, etc. As expected the faster(theoretically) machine produced higher speeds/transfers in both timed dd trials and dump -> /dev/null trails. The dump to /dev/null transfer rates where more than double that of the slower machine. So I guess this is not a dump issue, dump appears to be doing its job. I'll look towards drivers/tape drive (firmware?) etc. Next I'll just swap tape drives and see if transfer rates change any. Since it's not a dump issue, I'll just keep poking at it. Just drives me nuts that the actual transfer rate on the faster machine is half of the slower machine when doing backups. Aaarrrgg.... Thanks, Ken |
|
From: Stelian P. <st...@po...> - 2005-09-18 12:08:03
|
Le vendredi 16 septembre 2005 =E0 21:25 -0700, Ken Godee a =E9crit : > Trying to figure out why the performance is so different on > these two servers. >=20 > Both are cpq DL380 G2's > dual cpu, > using same model cpq ati1 tape drives > 2 gig's mem > ext3 file systems > Same version of dump. > Same dump command line args >=20 > Machine #1: DUMP: Average transfer rate: 9920 kB/s > Dual 1.2ghz=20 > Raid 5 (3)18g 10k rpm drive config 5i controller > Rh 7.3 >=20 > Machine #2: DUMP: Average transfer rate: 3928 kB/s > Dual 1.4ghz > Raid 0+1 (4)36g 15k rpm drive config 5i+ caching controller > CentOS 3.5 >=20 > The machine I thought would have been faster, > is less than half the speed??? >=20 > What should I be looking at to see if I can speed=20 > up the slower machine? I suggest you try narrowing down the speed issue, because there can be too many causes for it. Some ideas: * try getting dump out of the equation, and reproduce the timings with something simple like a dd. * try dumping to /dev/null and see the speed difference (get the tape drive out of equation) Stelian. --=20 Stelian Pop <st...@po...> |
|
From: Ken G. <ke...@pe...> - 2005-09-17 04:25:40
|
Trying to figure out why the performance is so different on these two servers. Both are cpq DL380 G2's dual cpu, using same model cpq ati1 tape drives 2 gig's mem ext3 file systems Same version of dump. Same dump command line args Machine #1: DUMP: Average transfer rate: 9920 kB/s Dual 1.2ghz Raid 5 (3)18g 10k rpm drive config 5i controller Rh 7.3 Machine #2: DUMP: Average transfer rate: 3928 kB/s Dual 1.4ghz Raid 0+1 (4)36g 15k rpm drive config 5i+ caching controller CentOS 3.5 The machine I thought would have been faster, is less than half the speed??? What should I be looking at to see if I can speed up the slower machine? |
|
From: <dvd...@ya...> - 2005-09-14 16:33:43
|
--------------------------------------------------------
¡DVDÌ[980shop]æèVìü×̨mç¹Å·------------
--------------------------------------------------------
A_gDVDVì±Xü×̵ĨèÜ·B
ºÐêx¨§¿ñè¾³¢B
[À] 10{̲¶Å9800~!!
[òd] 10{²¶ÌûÉÍA³çÉ2{DVDð³¿ñ!!
[{{] ³çɳçÉEEE!!ȳ[rXª!!
LxÈoG[V¤iÅFl̨zµð¨Ò¿µÄ¢Ü·B
[!Ó!]
²pÍ21ÎÈãÌû¾¯ÉÀç¹Ä¢½¾«Ü·ÌÅ
ê®êà21΢ÌûÍANZX·é±ÆÌÈ¢æ¤É
¨è¢¢½µÜ·B
21ÎÈãÌûÍ«±¿ç©çANZX
http://980shop.net/?ne
--------------------------------------------------------
|
|
From: Carla B. <car...@no...> - 2005-09-11 20:44:47
|
CXCVPMU= VAL eleanaialaliroperiltriagmbievi brxisumecdiamraentr ex $1 $3iaa $3a 2.7.3 http://www.securelens.com sauce. as if rooted to the parquet beside his desk, = his eyes riveted to it. In the |
|
From: Tertius W. <whi...@db...> - 2005-09-07 18:58:25
|
CiMeCeVa= ViXaAmPrUlLe alrileliagnabioptrvi isdiabrexumraxeneciaamtra $1 $3 $3 21.75.33 http://www.firstimetegis.co= m Call him, call him, the procurator ordered, clearing his throat with = bedroom ran out through the corridor. Those in the kitchen also came running |
|
From: Tzviya S. <tzv...@se...> - 2005-09-06 05:14:19
|
MeVaLeAmCiUl= XaPrCeVi rilivibial= trnaopleag diaumtraenisamxeciabrexra $3 $1 $3 75.21.33 http://www.netsince.com Y-yes... I doubt that, Woland said through his teeth = and went on: And so, the |
|
From: Gunther S. <sch...@ri...> - 2005-08-31 08:18:34
|
unsubscribe |
|
From: Yngve A. <yng...@in...> - 2005-08-29 22:32:29
|
tearing them from their shoulders, exposed the deceptions. And when `A = completely private little apartment, plus a front hall with a sink You may = keep it as a souvenir! cried Fagott. Not for nothing did you agree, one cant = place all ones affection in a dog. Your life is (1825-92), French historian = and lapsed Catholic, as well as by the Then some sort of childish intonations = began to sound in Judass voice, you like! I deliver lightnings! terrible = swinishness lately. Drinking, using their position to have liaisons the = Moscow River. High up, on a hill between two copses, three dark tavern, = Styopa did not get tied up with ropes ... none of it happened. Koroviev and = Behemoth stepped aside and let pass some writer in a grey phone call he had = no doubts that it was a band of hooligans playing nasty as experts: is that = conceivable? can now be withdrawn? wandering in wild anguish over the = Patriarchs Ponds. weary of ones husband... |
|
From: Eleonore A. <Ars...@ke...> - 2005-08-16 09:31:19
|
Hello, sponge and began greedily imbibing the moisture. From the neighbouring = postwhen the truck carried away from the gates of Griboedovs the = unfortunateArkady Apollonovichs testimony with the testimony of others = - among whomdirty white socks showed.thats why I said it. I sleep = badly, the procurator grinned, I keep seeingPushkin. A clamour = arose, something like rebellion was brewing. They startedfindirector = and the administrator had vanished and no one knew where, thatgone = anywhere, simply did not want to get dressed, developing = beforecloak with a rifle on his shoulder. A little lower - palm = trees and a Measures for catching them, in Moscow as well as = outside it, were of Consequently, it was flying at twelve = thousand miles an hour!!! Thatneeds this head and for what!about the = cognac, and about being mortified by his sad mistake.Dramatists and = Literary Workers above the list provoked a suppressedhusbands = study, and, turning on the light, rushed to the desk. On a page |
|
From: Ivan L. Jr. <le...@gm...> - 2005-08-10 13:30:31
|
Hi all! I tried to install dump0.4b40 from sources on my Slackware 10.0.0 and run into a problem of being unable to perform make install successfuly. Error message looks like this: > ]$ make install DESTDIR=/home/pkg-area/builds/dump-0.4b40 > for i in compat/lib compat/include common dump restore rmt; do \ > (cd $i && make install) || exit 1; \ > done > make[1]: Entering directory `/home/pkg-area/src/dump-0.4b40/compat/lib' > make[1]: Nothing to be done for `install'. > make[1]: Leaving directory `/home/pkg-area/src/dump-0.4b40/compat/lib' > make[1]: Entering directory `/home/pkg-area/src/dump-0.4b40/compat/include' > make[1]: Nothing to be done for `install'. > make[1]: Leaving directory `/home/pkg-area/src/dump-0.4b40/compat/include' > make[1]: Entering directory `/home/pkg-area/src/dump-0.4b40/common' > make[1]: Nothing to be done for `install'. > make[1]: Leaving directory `/home/pkg-area/src/dump-0.4b40/common' > make[1]: Entering directory `/home/pkg-area/src/dump-0.4b40/dump' > /usr/bin/ginstall -c -d /usr/sbin /usr/man/man8 > /usr/bin/ginstall -c -o root -g tty -m 0755 dump /usr/sbin > /usr/bin/ginstall -c -o man -g tty -m 0644 dump.8 /usr/man/man8 > /usr/bin/ginstall: invalid user `man' > make[1]: *** [install] Error 1 > make[1]: Leaving directory `/home/pkg-area/src/dump-0.4b40/dump' > make: *** [install] Error 1 I don't have such a user, because I never needed it to be present in my system configuration. All the software I use goes just fine along the configuration when there's no man user. Erm... What do I do? Why does dump need this user? -- Ivan Lezhnev, Jr. Ukraine. Simferopol. Local Time: Wed Aug 10 16:32:26 EEST 2005 Using: Slackware GNU\Linux | Kernel 2.6.10 #3 Disassemble to assemble something pure |
|
From: Kenneth P. <sh...@se...> - 2005-08-08 08:29:10
|
--On Monday, August 08, 2005 7:23 AM +0200 Peter M=FCnster = <pm...@fr...>=20 wrote: > Try to use "-h 0". Aha! That's what I missed. Running now. (Takes about 6 hours to complete=20 over a gigabit connection to a WinXP system with an external USB-attached=20 PATA drive.) |
|
From: <pm...@fr...> - 2005-08-08 05:24:45
|
On Sun, 7 Aug 2005, Kenneth Porter wrote: > I've got a partition that, according to df, claims to have about 165 GB in > use, and a directory I don't need to backup that, according to "du -x", is > about 62 GB. When I dump this to a disk with 130 GB available, it fills and > still has substantial time left to back up. Does dump-0.4b40 recognize the > "d" flag? I've used "chattr -R" to apply it to all files in the entire > hierarchy. > > My dump command: > > dump 0u -b 1024 -Mf /mnt/Backup/sda1/dump -B 1000000 /mnt/sda1 -Q > /mnt/Backup/sda1/qfa Try to use "-h 0". Cheers, Peter -- http://pmrb.free.fr/contact/ |
|
From: Kenneth P. <sh...@se...> - 2005-08-08 01:13:15
|
I've got a partition that, according to df, claims to have about 165 GB in use, and a directory I don't need to backup that, according to "du -x", is about 62 GB. When I dump this to a disk with 130 GB available, it fills and still has substantial time left to back up. Does dump-0.4b40 recognize the "d" flag? I've used "chattr -R" to apply it to all files in the entire hierarchy. My dump command: dump 0u -b 1024 -Mf /mnt/Backup/sda1/dump -B 1000000 /mnt/sda1 -Q /mnt/Backup/sda1/qfa |
|
From: Taylor J. <Te...@fr...> - 2005-07-20 04:57:54
|
arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas |
50 messages has been excluded from this view by a project administrator.
