Re: dump fails with bread and lseek trouble
Hi, This pops up every few weeks here on the list, its very simple: you are backing up an active filesystem with a tool designed primary for backing up filesystems mounted read-only. what happens is: dump first reads in the directory and filepositions on the disk(Pass I and II) then in pass III it reads from these stored places the information contained in these dirs and files. Now between mapping dirs and dumping a file was deleted or something and the corresponding blocks where freed and reused for another file. at this point dump thinks the block contains structural information, but in reality it contains data. so dump interprets more or less random data as block and sector-adresses. these adresses will most likely be rubish and way out of the limits of the disk. the result are the seek-errors you see. At this seems not too problematic, only the corresponding file should be rubish in your dump. But if you are unlucky these errors lead to completly unusable dumps. This had been widely discussed earlier this year, if you are interested in more details, read the archives. The topic why it came up was linux-dump and linus thorvalds advise not to use it with kernels 2.4.x. have a nice day Christoph Paul Lussier schrieb: In a message dated: Fri, 14 Dec 2001 09:29:54 GMT Thomas Robinson said: Hi, Has anyone seen or hear of this problem. Ayup, I get it all the time. I have no idea what the problem is though. It seems to come and go sporatically. I've run e2fsck -c /dev/sda5 to no avail. I also upgraded the dump utility tha t came with the standard Red Hat 7.1 install to dump-04b21 to dump-04b22. Any ideas what can cause this and how I might fix it? No, but if anyone has any ideas, please post them to the list, I'll try anything :) Thanks, -- Seeya, Paul God Bless America! ...we don't need to be perfect to be the best around, and we never stop trying to be better. Tom Clancy, The Bear and The Dragon
Status of the amanda-win32 project?
Saw it on Sourceforge: http://sourceforge.net/projects/amanda-win32/ Anyone tried it? -- |Colin Smith: [EMAIL PROTECTED] |
RE: [Amanda-users] Amanda+Samba : exclude setting
Trying to use a STT2A with nht0 was a DISASTER! amlabel could write labels, but not read them, so I couldn't even get started with amdump. Worse, attempts to run amdump or amlabel caused the machine to freeze completely on occasion, requiring a power-cycle reboot... No such problems with nst0... -Original Message- From: Jason Thomas [mailto:[EMAIL PROTECTED]] Sent: 15 December 2001 03:17 To: Philip Cooper Cc: amanda-users Subject: Re: [Amanda-users] Amanda+Samba : exclude setting On Fri, Dec 14, 2001 at 07:01:36PM -, Philip Cooper wrote: It seems to work fine, once I realised you had to enable the ide-scsi kernel module and use /dev/nst0 instead of /dev/nht0... (this would be a good addition to the FAQ). why would this matter, aren't they both block devices?
Re: dump fails with bread and lseek trouble
[ On Saturday, December 15, 2001 at 12:40:56 (+0100), Christoph Scheeder wrote: ] Subject: Re: dump fails with bread and lseek trouble This pops up every few weeks here on the list, its very simple: you are backing up an active filesystem with a tool designed primary for backing up filesystems mounted read-only. or not mounted at all! ;-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: dump fails with bread and lseek trouble
On Sat, Dec 15, 2001 at 11:10:41AM -0500, Greg A. Woods wrote: [ On Saturday, December 15, 2001 at 12:40:56 (+0100), Christoph Scheeder wrote: ] Subject: Re: dump fails with bread and lseek trouble This pops up every few weeks here on the list, its very simple: you are backing up an active filesystem with a tool designed primary for backing up filesystems mounted read-only. or not mounted at all! ;-) Hi, Greg! Not that my own favorite, tar, necessarily does any better in the sense of being guaranteed to always preserve completely consistent data from an active filesystem. If I make corresponding changes in files a and b during backup, but backup grabs a before the change and b after, my restore won't get back quite what I want. But, since it doesn't attempt to descend inside the filesystem's data structures, but only uses the user-eye view of what's there, it won't produce quite so many threatening messages. Bottom line is that it is difficult to make a good picture with a slow shutter of something that's moving fast. It's up to the admin to decide, case-by-case, when the picture is good enough. -- - Dan Wilder [EMAIL PROTECTED] Technical Manager Editor SSC, Inc. P.O. Box 55549 Phone: 206-782-8808 Seattle, WA 98155-0549URL http://embedded.linuxjournal.com/ -
