strange fbackup error

[Glen Liu]

sysadms,

I once got fbackup error messages as below:

fbackup(9999): I/O error
fbackup(2004): reader 1: 1st read error, firstread=16384, n=-1
fbackup(9999): I/O error
fbackup(9999): I/O error
fbackup(2004): reader 1: 1st read error, firstread=16384, n=-1
fbackup(2004): reader 0: 1st read error, firstread=16384, n=-1
fbackup(9999): I/O error
fbackup(2004): reader 1: 1st read error, fbackup(2004): reader 0: 1st read error
, firstread=32768, n=-1
firstread=16384, n=-1
fbackup(2004): reader 1: 1st read error, firstread=147456, n=-1
fbackup(9999): I/O error

It happened when it's backuping up a big file. But it didn't happened every time I backup this file. I cannot find information about these error numbers. Anyone knows that? Thanks.

[Bill Hassell]

The only important part in this error list is: I/O error

You have a bad tape or a dirty tape drive. Be sufe to run the cleaning tape regularly.

[Glen Liu]

Thanks, Bill.

But it once happened right after the tape drive was replaced. I forgot to tell more about the big file in my last post. It was generated every day right before it was backuped. Another point is I once encountered the same error while I was backuping another big file on another server. What I did was just regenerated the file. And then the backup was completed without error. I was using the same tape and same drive without any extra cleaning.

So I doubt if it's led by some property of the file. It may be size, content or etc.. Do you have any idea? What's more, do you know where can I find the documents about the (9999) and (2004) error code of fbackup?

[Glen Liu]

And it's a reader error...

[Mark Vollmers]

Hi-

Could the file be opened somewhere and the backup is having a problem working with it because it is being modified? Just a thought.

Mark

[Tim Malnati]

Unfortunately, fbackup/frecover are not documented well in terms of their error messages.

After reviewing your output several times it appears that the file itself is changing in some strange ways. I'm wondering if the application is somehow causing the inode to shift. Most apps simply write back to the same file and fbackup usually responds to this well. It does this by looking at the inode modification times before and after it goes to tape and repeats it if it has changed. If the inode is changing through something like a modify to new file, delete original, and move new to original name action; fbackup will certainly burp.

[Bill Hassell]

Tim has a handle on the problem. I would use fuser (or get lsof from the Liverpool archives) and see what process has the file open. Stop the process and see if fbackup works OK. Unfortunately, fbackup (like many Unix utilities) does not tie error messages to the source (input or output).

[Glen Liu]

I'd tryed to use "fuser -u filename" but found nothing. So I named it a "strange" error message.