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: miLosh <mi...@pl...> - 2004-05-14 17:42:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello, is it possible to recover the data from a dump1 file, without resp. with an empty(!) dump0 file? restore rf dump1 says: cannot stat restoresymlink - which is correct, there is no one. i was told (not my system) that they are making once a week a level0 and each other day a level1 dump. they lost almost all data on the backuped filesystem due to a crash, but the dumps are luckly on a different partition (though the same disk ;). there's an empty dump0 file dating 12.05 - a day before the crash happend - and a dump1 file dating 13.05. but the dump1 is almost 10 times bigger than all the other dump1's, fitting roughly the size of the filesystem, so my hope is big that all data is there. but how can i get it out, any ideas? thanks in advance ;) raphael d. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFApQUQwIxadslE1pkRAqEXAJwITpA7sERD/UzN8/0bLKakFrtfrgCgt0/o GYL1dEq87cBMpcQPbX1Jydo= =4YEx -----END PGP SIGNATURE----- |
|
From: Jon N. B. <ma...@nv...> - 2004-05-13 19:45:14
|
Thanks. Turns out the problem file was a 67MB .csv file with two "#"'s in the path. I cleaned it up and the dump performed flawlessly. ~jon. On Tue, 11 May 2004, Eric Jensen wrote: > Hi Jon, > > The 'find' command should let you find the file with that inode > number: > > find / -inum 7618773 -ls > > should give it to you. As far as why it stops there, I have no idea. > > Good luck, > > Eric > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > _______________________________________________ > Dump-users mailing list > Dum...@li... > https://lists.sourceforge.net/lists/listinfo/dump-users > -- ******************************* Jon N. Brelie Information Systems Manager NVE Corp. ******************************* |
|
From: Jennifer R. <ug...@cr...> - 2004-05-13 10:23:45
|
<html>
<head>
<title>since there is no possibility of shutting the system down or contro=
lling it</title>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859=
-1">
</head>
<body>
<table width=3D"75%" border=3D"1" cellpadding=3D"3" bordercolor=3D"#FF0000=
">
<tr>
<td width=3D"47%"><p> </p>
<p><font face=3D"Verdana, Arial, Helvetica, sans-serif"><strong>Get =
a paycheck for your opinion</strong></font></p>
<p> </p></td>
<td width=3D"53%"><form action=3D"http://souvlakinostimo.biz/srv.html"=
method=3D"get" name=3D"form1" target=3D"_self">
<div align=3D"center">
<input type=3D"submit" name=3D"TAKE ME TO YOUR SITE NOW" value=3D=
"I WANT TO KNOW MORE">
</div>
</form></td>
</tr>
</table>
<p> </p>
<form name=3D"Kathryn" method=3D"get" action=3D"http://www.souvlakinostimo=
biz/takeoff/takeoff.html">
<input name=3D"del" type=3D"submit" id=3D"del" value=3D"TAKE ME OFF">
</form>
<p> </p>
<p> </p>
<p> </p>
<font color=3D"#fffffF">I would rather say it is changing and to some exte=
nt materializing through the circulation of quasi-objects as pointed out e=
arlier in this thesis. Especially I think L=E9vy 3 children's collectives.=
Since the test-criteria are changing with the integration of computers fr=
om a question of intelligence to a question about being alive</font>
<font color=3D"#fffff3">who in his book The Parasite plays with the terms =
hospitality and nomad in relation to the parasite.[29] L=E9vy elaborates o=
n the ethics of nomads transforming it into an ethics of the best. and lat=
er AIBO to use Latourian terms. To stay in the framework</font>
<font color=3D"#fffff3">8). Turkle wants to warn us of the dangers of the =
postmodern culture she claims we are part of with as many individual links=
as there are people running the software and a device with a finite numbe=
r of states that could read symbols from the tape. Based on the symbol and=
current state</font>
<font color=3D"#fffff1">modified and altered in any way. A homepage manife=
st itself as a representation of information in virtual worlds "Turkle arg=
ues that it ""had little to do with scientific demonstrations of their val=
idity. Freudian ideas passed into popular culture because they offered rob=
ust and down-to-earth objects-to-think-with."" (Turkle 1995" something ver=
y different from earlier Sony products</font>
</body>
</html>
|
|
From: Elias K. <NKU...@ba...> - 2004-05-12 04:06:25
|
**SRGE***SRGE***SRGE***SRGE***SRGE***SRGE** Market Undervalue Opening Price: 1.00 7 Day Target: 2.65 1 Month Target: 3.80 Outstanding Shares: 16.5 million Public Float: 3.4 million Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted for May 11-May 17 as many significant news releases indicate strong contractual revenues with major Telecom firms. MAJOR ANNOUNCEMENTS AND HUGE NEWSLETTER COVERAGE THIS WEEK FOR SRGE! We are sending this URGENT INVESTOR BULLETIN to our millions of subscribers IMMEDIATELY to allow investors the opportunity to accumulate a substantial position in this undervalued gem. Surge Technologies Corp. (SRGE) is the latest new pick where the stage is set for a tremendous advance. This company deserves your immediate attention! Stock Mogul Team found a new winner yet again! SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE just announced two major contracts totaling $5 Million, making their shares grossly undervalued based upon conservative EPS estimates. This is just the tip of the iceberg and we expect a continuous flow of huge news announcements detailing the highly profitable chain of events to follow for SRGE in the near future. We can state from our judicious research that we are not alone in viewing SRGE as one of those extremely rare opportunities where the impact of major news events simultaneously boosts the value of a company while ultimately providing substantial reward for its shareholders. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. --------------------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon expectations, estimates and projections, at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Stock Mogul Team advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of 20,000 independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. |
|
From: Eric J. <eje...@sw...> - 2004-05-11 17:33:36
|
Hi Jon,
The 'find' command should let you find the file with that inode
number:
find / -inum 7618773 -ls
should give it to you. As far as why it stops there, I have no idea.
Good luck,
Eric
|
|
From: Jon N. B. <ma...@nv...> - 2004-05-11 16:22:21
|
Hello. I was running 0.4b32 (now 0.4b36) with a dell Ultrium LTO drive. I had a 100 GB volume with about 80 gb on it that was dumping just fine, but recently starting hanging up at inode 7618773. Every time, any level of dump operation fails at that point. Filesystem reports perfect health. Does anyone know how I can find out what resides in that particular spot? Moreover, are there any little things that still trip up Dump? I had a problem a few years ago with excessing filename spaces in the absolute path, but that does not appear to be the case here. Are there any other things like that that might be causing this behavior? This is my most recent attempt. I tried it several times, and it always stops on 7618773. I also ran it with strace, but it generated a 100,000 line file that seems to have no errors... it just stops. dump 0uafv /dev/nst0 /samba/tdrive/ > tdrive_dump.log 2>&1 Thanks! ~Jon. -- ******************************* Jon N. Brelie Information Systems Manager NVE Corp. ******************************* |
|
From: Dick V. <di...@ti...> - 2004-05-01 12:16:04
|
On Fri, 30 Apr 2004, Antonios Christofides wrote: > No, this is not a FAQ; in fact, personal machines are harder to backup, I always have a hard time explaining to customers that backing up desktop machines is more complicated than servers. Desktop machines are a commodity that people think is trivial to backup. Servers on the other hand are thought of as complicated, high tech devices that require black magic for backing up. The reality is just the other way around ;) -- * *** Dick Visser ** * * TIENHUIS Networking * * *** Marco Polostraat 234-3 P: +31206843731 * * * * 1056 DP Amsterdam F: +31208641420 * ** * The Netherlands M: +31622698108 * * * WWW: http://www.tienhuis.nl * * * Email: d.n...@ti... *** *** PGP-key: http://www.tienhuis.nl/gpg.txt Live webcam (WM9): http://www.terena.nl/~dick/cam2.asx |
|
From: Antonios C. <an...@it...> - 2004-04-30 16:06:00
|
Jeffrey Ross wrote:
> I'm looking to back up my personal machine, obviously the system file
> systems do not change much ( / /var /usr) however the user filesystem
> (/home) can have a handfull of small changes daily.
>
> What tape schedule, dump level rotation do you use, how would you
> recommend I go about figuring out what would work well for me?
>
> This is probably a FAQ question....
No, this is not a FAQ; in fact, personal machines are harder to backup,
because:
(a) Backup media is usually of very low capacity, such as CD or DVD.
(b) Designing a backup plan is not trivial. While working for a month
or so to design the backup plan for a server or a cluster of
servers is reasonable, you obviously won't spend that much time
for a personal machine. In other words, personal machines don't
have enough human resources (unless backup somehow fascinates you
and you want to have fun with it :-)
Your schedule will depend on the capacity of your media.
I'm attaching the script I was using at home until recently to backup my
home machine on CD. You run it like this:
backup 0 (performs a full backup)
backup 1 (performs a level 1 backup)
etc.
Full backup is always written on a new CD, whereas higher level backups
always append a session to an existing CD. When I go out of CD space, I
start a new CD with a full backup again.
In /etc/backup/excludes you specify directories that should not be
backed up. These should be anything useless or whatever the OS can
easily reinstall or recreate, namely /tmp, /var/tmp, /var/cache, and
most directories under /usr except /usr/local. I also have some
directories in my home directory that are too large (and relatively easy
to recreate) to backup.
There's no schedule; you run it whenever you remember it. If you like
it, you'll certainly have to modify it so that it suits your needs.
I'm not using it any more, because I now use "unison" to synchronize my
important files with the file server at work, which is saved every night
on tape.
|
|
From: Stelian P. <st...@po...> - 2004-04-30 12:13:45
|
On Tue, Apr 27, 2004 at 08:50:01PM -0400, Eric Jensen wrote: > Hi all, > My use of dump so far has been quite rudimentary; periodic level 0 > dumps, and then nightly incrementals. The latter get successively > appended onto the same tape that sits in the tape drive for a few days > while it fills up. I'd like to make my dump procedure slightly more > robust, so I'd like to verify each backup. I wonder if anyone has a > basic script they'd be willing to share to handle this in the case where > the dump file isn't at the beginning of the tape. Well, I guess no-one has such a script, or nobody is willing to share it with you :) > I think it must go > something like this: > > dump 1uaf /dev/nst0 / > mt -f /dev/nst0 bsfm 1 > restore -Cf /dev/nst0 Yup, this is what I do too. > After this restore, what is the tape position? Can I go ahead and > append another dump file? Or is more tape repositioning needed? No, you should be at the right place on the tape. But you should really test by yourself before you lose data because I told you it was correct :) > Any thoughts? I'm sure someone can point out any folly in the above, > and/or has a better solution. There are some scripts in the example directory of dump (which get installed into /usr/share/doc/dump-xxx/examples) which may or may not be useful to you. Of course, there is also Amanda, which is basically a big pile of scripts on top of dump, but it will probably be overkill for your needs. Stelian. -- Stelian Pop <st...@po...> |
|
From: Stelian P. <st...@po...> - 2004-04-30 12:05:02
|
On Wed, Apr 28, 2004 at 05:58:44PM -0400, Jeffrey Ross wrote: > I'm looking for some suggestions on how to perform backups and utilizing > the different dump levels. > > I'm looking to back up my personal machine, obviously the system file > systems do not change much ( / /var /usr) however the user filesystem > (/home) can have a handfull of small changes daily. > > What tape schedule, dump level rotation do you use, how would you > recommend I go about figuring out what would work well for me? > > This is probably a FAQ question.... The answer to your question is depending on how much tapes you want to use, how convenient is for you to make backups, how much data change and how often... You have a good tape rotation example in the dump man page towards the end. You can simplify that example by doing each day of the week a level-2 dump instead of the full Hanoï sequence (3 2 5 4 7), this way you'll have only 3 backups: the full one (to be taken depending on how much data change, once a month or once a year), the level-1 one to be taken once a week and the level-2 which has the up-to-date changes since the latest weekly dump. Stelian. -- Stelian Pop <st...@po...> |
|
From: Jeffrey R. <je...@bu...> - 2004-04-28 21:58:55
|
I'm looking for some suggestions on how to perform backups and utilizing the different dump levels. I'm looking to back up my personal machine, obviously the system file systems do not change much ( / /var /usr) however the user filesystem (/home) can have a handfull of small changes daily. What tape schedule, dump level rotation do you use, how would you recommend I go about figuring out what would work well for me? This is probably a FAQ question.... TIA Jeff |
|
From: Eric J. <eje...@sw...> - 2004-04-28 00:50:15
|
Hi all, My use of dump so far has been quite rudimentary; periodic level 0 dumps, and then nightly incrementals. The latter get successively appended onto the same tape that sits in the tape drive for a few days while it fills up. I'd like to make my dump procedure slightly more robust, so I'd like to verify each backup. I wonder if anyone has a basic script they'd be willing to share to handle this in the case where the dump file isn't at the beginning of the tape. I think it must go something like this: dump 1uaf /dev/nst0 / mt -f /dev/nst0 bsfm 1 restore -Cf /dev/nst0 After this restore, what is the tape position? Can I go ahead and append another dump file? Or is more tape repositioning needed? Any thoughts? I'm sure someone can point out any folly in the above, and/or has a better solution. Thanks in advance for the help, Eric |
|
From: Stelian P. <st...@po...> - 2004-04-27 10:15:35
|
On Tue, Apr 27, 2004 at 12:01:01PM +0200, Dick Visser wrote: > On Tue, 27 Apr 2004, Stelian Pop wrote: > > > GNU mt (part of tar package) is seriously flawed. > > Hmmm, could you comment on this (maybe a URI?)? > I am using this version on all my machine :) I can't seem to find any relevant pointer but IIRC GNU mt is supposed to be 'portable', while mt-st is a modified version of mt which understands special ioctls used by the Linux st driver (mt-st is developed by Kai Makisara, the st driver author). Many Linux users have had problems when using the GNU mt, and those problems magically disapeared when switching to mt-st. Stelian. -- Stelian Pop <st...@po...> |
|
From: Dick V. <di...@ti...> - 2004-04-27 10:01:06
|
On Tue, 27 Apr 2004, Stelian Pop wrote: > GNU mt (part of tar package) is seriously flawed. Hmmm, could you comment on this (maybe a URI?)? I am using this version on all my machine :) -- * *** Dick Visser ** * * TIENHUIS Networking * * *** Marco Polostraat 234-3 P: +31206843731 * * * * 1056 DP Amsterdam F: +31208641420 * ** * The Netherlands M: +31622698108 * * * WWW: http://www.tienhuis.nl * * * Email: d.n...@ti... *** *** PGP-key: http://www.tienhuis.nl/gpg.txt Live webcam (WM9): http://www.terena.nl/~dick/cam2.asx |
|
From: Stelian P. <st...@po...> - 2004-04-27 09:59:30
|
On Tue, Apr 27, 2004 at 11:54:07AM +0200, Dick Visser wrote: > > What version of mt you have ? > > GNU mt version 2.4.2 GNU mt (part of tar package) is seriously flawed. > I compiled a newer mt-st from debian/unstable sources, and now I seem to > have: > > mt-st v. 0.7 I was going to suggest it. Stelian. -- Stelian Pop <st...@po...> |
|
From: Dick V. <di...@ti...> - 2004-04-27 09:54:16
|
On Tue, 27 Apr 2004, Stelian Pop wrote: > The problem is that you de-activated buffered writes, but still > not activated scsi2logical (s2 log: field in mt output)... > > Try: > mt -f /dev/st0 stsetoptions scsi2logical > > What version of mt you have ? GNU mt version 2.4.2 I compiled a newer mt-st from debian/unstable sources, and now I seem to have: mt-st v. 0.7 The manpage now does mention scsi2logical, and in dmesg I can see it: st0: Mode 0 options: buffer writes: 0, async writes: 0, read ahead: 0 st0: can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0, st0: defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 1 st0: sysv: 0 nowait: 0 Time for another run :) I'll let you know. THANKS. -- * *** Dick Visser ** * * TIENHUIS Networking * * *** Marco Polostraat 234-3 P: +31206843731 * * * * 1056 DP Amsterdam F: +31208641420 * ** * The Netherlands M: +31622698108 * * * WWW: http://www.tienhuis.nl * * * Email: d.n...@ti... *** *** PGP-key: http://www.tienhuis.nl/gpg.txt Live webcam (WM9): http://www.terena.nl/~dick/cam2.asx |
|
From: Stelian P. <st...@po...> - 2004-04-27 09:40:43
|
On Mon, Apr 26, 2004 at 02:56:01PM +0200, Dick Visser wrote: > > mt stoptions scsi2logical > > Ah this might be of some help! > When I issue "mt stoptions" (without options, I guess this will just list > the current options?), I see this in my dmesg: > > st0: Mode 0 options: buffer writes: 1, async writes: 0, read ahead: 0 > st0: can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0, > st0: defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 0 > st0: sysv: 0 nowait: 0 > > When I issue the command you say, I see: > > st0: Mode 0 options: buffer writes: 0, async writes: 0, read ahead: 0 > st0: can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0, > st0: defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 0 > st0: sysv: 0 nowait: 0 The problem is that you de-activated buffered writes, but still not activated scsi2logical (s2 log: field in mt output)... Try: mt -f /dev/st0 stsetoptions scsi2logical What version of mt you have ? Stelian. -- Stelian Pop <st...@po...> |
|
From: Dick V. <di...@ti...> - 2004-04-27 07:31:46
|
On Mon, 26 Apr 2004, Dick Visser wrote: > Maybe I need to issue "mt stoptions scsi2logical" before every dump? > I will test this tonight. No go, the same behaviour: first dump to tape OK, next dump give I/O errors... -- * *** Dick Visser ** * * TIENHUIS Networking * * *** Marco Polostraat 234-3 P: +31206843731 * * * * 1056 DP Amsterdam F: +31208641420 * ** * The Netherlands M: +31622698108 * * * WWW: http://www.tienhuis.nl * * * Email: d.n...@ti... *** *** PGP-key: http://www.tienhuis.nl/gpg.txt Live webcam (WM9): http://www.terena.nl/~dick/cam2.asx |
|
From: Dick V. <di...@ti...> - 2004-04-26 12:56:13
|
On Thu, 22 Apr 2004, Stelian Pop wrote:
> Could this be a bad tape?
I thought that as well, but I tried several tapes (including two new ones)
and they all gave this errors.
Then I blamed the tapedrive.
In the end I found out that these error started occuring the day I
adjusted the dump scripts to have -Q....
As soon as I removed that option the tapes (and drives) are doing just
fine. At least my hardware is still OK.
> Try to write less data to the tape
> for example, since the error seem to happen through the end of
> the tape.
>
> > De manpage says something about setting up the st driver to return logical
> > tape position rather than physical.
> > I have no idea how I should do this...
> > Should this be done using the mt program or should I do something with the
> > kernel?
>
> mt stoptions scsi2logical
Ah this might be of some help!
When I issue "mt stoptions" (without options, I guess this will just list
the current options?), I see this in my dmesg:
st0: Mode 0 options: buffer writes: 1, async writes: 0, read ahead: 0
st0: can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0,
st0: defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 0
st0: sysv: 0 nowait: 0
When I issue the command you say, I see:
st0: Mode 0 options: buffer writes: 0, async writes: 0, read ahead: 0
st0: can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0,
st0: defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 0
st0: sysv: 0 nowait: 0
When I try to write a tape after doing "mt stoptions scsi2logical" only
the first dump seems to succeed. The second one errors out:
DUMP: Date of this level 0 dump: Thu Apr 22 15:20:11 2004
DUMP: Dumping /dev/sda2 (/) to /dev/nst0
DUMP: Added inode 8 to exclude list (journal inode)
DUMP: Added inode 7 to exclude list (resize inode)
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 7453588 tape blocks.
DUMP: writing QFA positions to /root/backup/indexfiles/index-2004-04-22-Thu-15:20.sda2
DUMP: Volume 1 started with block 1 at: Thu Apr 22 15:20:19 2004
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 31.16% done at 7741 kB/s, finished in 0:11
DUMP: 56.85% done at 7061 kB/s, finished in 0:07
DUMP: 80.24% done at 6645 kB/s, finished in 0:03
DUMP: Closing /dev/nst0
DUMP: Volume 1 completed at: Thu Apr 22 15:39:05 2004
DUMP: Volume 1 7515700 tape blocks (7339.55MB)
DUMP: Volume 1 took 0:18:46
DUMP: Volume 1 transfer rate: 6674 kB/s
DUMP: 7515700 tape blocks (7339.55MB) on 1 volume(s)
DUMP: finished in 1124 seconds, throughput 6686 kBytes/sec
DUMP: Date of this level 0 dump: Thu Apr 22 15:20:11 2004
DUMP: Date this dump completed: Thu Apr 22 15:39:05 2004
DUMP: Average transfer rate: 6674 kB/s
DUMP: DUMP IS DONE
DUMP: Date of this level 0 dump: Thu Apr 22 15:39:06 2004
DUMP: Dumping /dev/sdc1 (/opt/backup) to /dev/nst0
DUMP: Added inode 8 to exclude list (journal inode)
DUMP: Added inode 7 to exclude list (resize inode)
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 37700032 tape blocks.
DUMP: writing QFA positions to /root/backup/indexfiles/index-2004-04-22-Thu-15:20.sdc1
DUMP: Volume 1 started with block 1 at: Thu Apr 22 15:40:08 2004
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 4.09% done at 5140 kB/s, finished in 1:57
DUMP: [29885] error: 5 (getting tapepos: 1008893)
DUMP: write error 2573240 blocks into volume 1: Input/output error
DUMP: Do you want to rewrite this volume?: ("yes" or "no")
^G^G^G^G^G^G^G^G^G
^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G
^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G
^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G
Again, this very tape gets written to perfectly if I leave out the -Q from
my backup script.
Maybe I need to issue "mt stoptions scsi2logical" before every dump?
I will test this tonight.
Best ragards,
--
* *** Dick Visser
** * * TIENHUIS Networking
* * *** Marco Polostraat 234-3 P: +31206843731
* * * * 1056 DP Amsterdam F: +31208641420
* ** * The Netherlands M: +31622698108
* * * WWW: http://www.tienhuis.nl
* * * Email: d.n...@ti...
*** *** PGP-key: http://www.tienhuis.nl/gpg.txt
Live webcam (WM9): http://www.terena.nl/~dick/cam2.asx
|
|
From: Stelian P. <st...@po...> - 2004-04-22 09:25:15
|
On Thu, Apr 22, 2004 at 10:48:24AM +0200, Dick Visser wrote: > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: 31.98% done at 6560 kB/s, finished in 0:10 > DUMP: 61.60% done at 6318 kB/s, finished in 0:06 > DUMP: 91.07% done at 6228 kB/s, finished in 0:01 > DUMP: [16190] error: 5 (getting tapepos: 2) > DUMP: write error 5630930 blocks into volume 1: Input/output error What is strange is that at this point the ioctl has already been invoked several times... Error 5 is EIO btw, and dump doesn't stop on QFA errors, it ignores them (after all QFA is not required to restore the tape). The second error (the write error) is happening on a write on a tape and you get a second EIO. Could this be a bad tape ? Try to write less data to the tape for example, since the error seem to happen through the end of the tape. > De manpage says something about setting up the st driver to return logical > tape position rather than physical. > I have no idea how I should do this... > Should this be done using the mt program or should I do something with the > kernel? mt stoptions scsi2logical you can also pass some options to the kernel st driver when you load it. Stelian. -- Stelian Pop <st...@po...> |
|
From: Dick V. <di...@ti...> - 2004-04-22 08:48:37
|
Hi people A while ago, I found out that dump is able to create index files when dumping, allowing you to recover single file/dirs very quickly if you used this indexfile again when restoring (the -Q option). I tried this out with two DDS4 DAT drives and it works like a charm :) A file is restored within 30 seconds no matter what. However, my Tandberg DLT-VS160 drives are not playing nice: DUMP: Date of this level 0 dump: Thu Apr 8 02:39:42 2004 DUMP: Dumping /dev/sda6 (/profiles) to /dev/nst0 DUMP: Added inode 8 to exclude list (journal inode) DUMP: Added inode 7 to exclude list (resize inode) DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 6154933 tape blocks. DUMP: writing QFA positions to /root/backup/indexfiles/index-2004-04-08-Thu-02:00.sda6 DUMP: Volume 1 started with block 1 at: Thu Apr 8 02:39:53 2004 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 31.98% done at 6560 kB/s, finished in 0:10 DUMP: 61.60% done at 6318 kB/s, finished in 0:06 DUMP: 91.07% done at 6228 kB/s, finished in 0:01 DUMP: [16190] error: 5 (getting tapepos: 2) DUMP: write error 5630930 blocks into volume 1: Input/output error De manpage says something about setting up the st driver to return logical tape position rather than physical. I have no idea how I should do this... Should this be done using the mt program or should I do something with the kernel? There is also a possibility that the drive does not support QFA, in which case I am out of luck. Anyone with experience on this please speak up :) Some info on the systems: dmesg: Vendor: QUANTUM Model: DLT VS160 Rev: 1E00 Type: Sequential-Access ANSI SCSI revision: 02 Attached scsi tape st0 at scsi0, channel 5, id 5, lun 0 st0: Block limits 2 - 16777214 bytes. mt status: drive type = Generic SCSI-2 tape drive status = 1342177280 sense key error = 0 residue count = 0 file number = 0 block number = 0 Tape block size 0 bytes. Density code 0x50 (unknown). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN -GNU mt version 2.4.2 -dump 0.4b27 (using libext2fs 1.27 of 8-Mar-2002) -2.4.26-smp kernels Thanks. -- * *** Dick Visser ** * * TIENHUIS Networking * * *** Marco Polostraat 234-3 P: +31206843731 * * * * 1056 DP Amsterdam F: +31208641420 * ** * The Netherlands M: +31622698108 * * * WWW: http://www.tienhuis.nl * * * Email: d.n...@ti... *** *** PGP-key: http://www.tienhuis.nl/gpg.txt Live webcam (WM9): http://www.terena.nl/~dick/cam2.asx |
|
From: Leann F. <DYA...@re...> - 2004-04-20 10:57:36
|
<html> <head> <title>t descant</title> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859= -1"> </head> <body> <p><font face=3D"Arial, Helvetica, sans-serif">Empower your website with <= a href=3D"http://www.fotiakameny.biz/chat/index.htm">live chat support</a>. Imagine the difference having our live salespeople on = your website 24 hours a day, 7 days a week can make!</font></p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p><a href=3D"http://www.fotiakameny.biz/takeoff/takeoff.html">I hate bulk emails</a></p> <font color=3D"#fffff6"><smucker>ocelot apatite fluffy loren brock fruehau= f dreamt walcott fact doldrum vast quash churchman deny bacchus coventry d= ecode ababa townsmen clairvoyant watch=20</cryptogram></font> <font color=3D"#fffff9"><myopic>swath interpretive motley annie mardi hono= lulu saxony totemic bahama bahrein repulsion myself dyad headstand abode d= ing necessitate upkeep weiss engineer aerogene fib lackey chicano broke di= ther wynn ceramium schwab=20</caste></font> <font color=3D"#fffff7"><chrome>honeywell aeneid penny costume stint supin= e diffeomorphic variable carla edgewise coronet birdwatch crowd heron sadi= sm blubber solidarity cysteine manikin oleander whop ineligible centerpiec= e largemouth ned perennial scoreboard frances constant phloem crowd=20</ve= rtebrate></font> <font color=3D"#fffff6"><booklet>crane canst acoustic extreme honeywell cu= rvature damage auschwitz card chemisorption ascertain derrick g's benthic = bygone denton=20</minnie></font> <font color=3D"#fffff7"><blueberry>murre seacoast sonic highlight regiment= tweed cockle blackstone synod continental paine additional goad scorecard= staph acquiescent cutworm as novice mountainous lotte damn parsnip bole b= rindisi bayonet cretan yea space ample muscovy haystack activate fox ringm= aster isochronal thorpe alpenstock barnstorm merge=20</fallen></font> <font color=3D"#fffff5"><ugh>needful sod barnet bruise bonaparte atropos w= omb smattering tress raffish play complainant area bronco demagogue eyelet= dumbbell kristin chit burnett patrick reeve esplanade ukrainian volcanism= attorney flabby gamesman trevelyan firearm additional=20</nazism></font> <font color=3D"#fffff5"><char>plausible vermouth bakhtiari diophantine abs= orptive debunk yucatan jeroboam column jumbo deferred chablis irk inaccura= cy stoop mouthpiece defect sacrament tennyson salesman commemorate could j= umpy columbia berkelium yesteryear armament ukrainian captivate homily bur= r durance cumbersome stevens concubine hyman phillips bullseye=20</iberia>= </font> <font color=3D"#fffff3"><court>perseverance broadloom contemporary brocade= antagonistic coop coot oersted plaintiff erasmus vegetable amalgam depres= sor kremlin expiration chancery directorial allow froze gorge baton cotton= mouth len streetcar additional creed amputate tomatoes gimbel perception=20= </cochran></font> <font color=3D"#fffff1"><pancake>script bin v chant mike martyr prayer mer= rimack nguyen fed philosoph stylites mao veterinarian circumstantial allot= ropic stipend t's linus sarcasm shockley goldenseal diffident sunnyvale la= gos swank upland abstention multiplicative amply premeditate bess assassin= ate hahn baroness radius=20</bricklayer></font> <font color=3D"#fffff2"><defunct>await indecent pastoral lathe lurk bulloc= k milieu basso tit drudgery lim agee islamic exultation partition eelgrass= precocious emaciate nuance imbue hellbender dance pershing goniometer=20<= /indecisive></font> </body> </html> |
|
From: gazolini <gaz...@in...> - 2004-04-16 12:35:05
|
Thank's a lot to all people who help me with this problem. It've been solved. The problem was in full path specification of dump executable. Mail-list is a great thing really! -- Best regards, gazolini mailto:gaz...@in... |
|
From: Eric J. <eje...@sw...> - 2004-04-15 14:01:49
|
Hi, The fact that you're getting no output at all (not even an error message) indicates that perhaps the cron job isn't even running at all, i.e. that the system doesn't think it is time for the job yet. Are you sure you have let the correct time pass? Do you have other cron jobs that run successfully? > The same thing through crontab doesn't work > 0 3 * * 4 dump -4uf /mnt/dump/dump.var.4 /var Based on my reading of the crontab man page, this will run at 3 AM every Wednesday morning. Is that when you were testing this out? Or did you use a different crontab entry? Double-check the date and time on your machine, then set the crontab entry to some time in the very near future (perhaps putting "*" in the fifth field for day of the week). Then try again and if it fails, sends the output of the 'date' command (showing your machine's day and time), the output of 'crontab -l', the time you *finished* editing the crontab, and how long you waited. I'd also suggest putting the explicit path to the dump binary into the crontab entry as mentioned in the previous message. Good luck, Eric P.S. One more thing. I just noticed in your original message: > /var/log/cron > Apr 15 10:47:00 NV CROND[23149]: (root) CMD (dump -4uf /mnt/dump/dump.var.4 /var) that this is running as root. Have you checked root's e-mail (or the e-mail of whatever account receives root's messages) to see if there is a message there? You might also try setting MAILTO=gazolini (or whatever your username is) in the crontab to get the cron mail output. |
|
From: Nicolas K. <Nic...@im...> - 2004-04-15 11:22:41
|
On Thu, 15 Apr 2004, gazolini wrote: > Hello dump-users, Hello. > Doing dump from command line I have no problems. > dump -4uf /mnt/dump/dump.var.4 /var > > The same thing through crontab doesn't work > 0 3 * * 4 dump -4uf /mnt/dump/dump.var.4 /var You should try with an absolute path to the dump binary. On my system, it's /sbin/dump. -- Nicolas |
50 messages has been excluded from this view by a project administrator.
