Currently -E makes life much easier for dump users,
the inodes can be easily placed into one file instead
of having 30 of them listed in a comma separated list
on the command line (which requires multiple
newlines). It is relatively simple to find the inodes
of a file, or a list of files via the stat command
(all the files in a directory are simply added to the -
E file by doing stat -t * | awk '{print $5}' >>
exclude_list.
However, there is still one problem associated with
this method. It is referencing files via their inodes.
On many systems dump will fail with the dreaded error:
DUMP: short read error from /dev/sda6: [sector -
1820642843]: count=512, got=0
DUMP: bread: lseek2 fails!
searches on google often give you the horrifying
feeling that your disk is failing, when this is not
always true. With an open logfile you can often get
this same error, specifically apache logfiles, squid
cache files, etc. Excluding these from the dump makes
this error go away, but it is a scary error.
So what is wrong? The flags -e and -E do their trick
just fine, as long as the inodes stay the same. Inodes
don't always stay the same, *especially* with
logfiles. Logfiles are often rotated, this means
removing the old logfile and creating a new one. This
also means the inode changes during this rotation.
Solution:
Change the -E option so that the exclude_list file can
contain actual file *names* and their corresponding
directories, and then do the stat() call on those
files in order to get their inodes right before the
dump happens and then exclude them.
Thanks for the excellent program, and for considering
this suggestion. I've thought many times that when I
get a free moment I will create this patch myself, but
so far I haven't found that free moment, so insteaed I
ask you here to implement this simple solution that I
believe would save many people headaches in having to
regenerate their inode list after every logfile
rotation.
Micah
Logged In: YES
user_id=5513
You analysis of the 'lseek' errors is correct.
However, you missed the fact that dump works in 2 passes:
first it maps the inodes to be dumped (traversing the
filesystem/directory, removing the inodes marked not to be
dumped etc), then in the second pass it dumpes the inodes
one by one.
In this second pass, there is no knowledge about the inodes
pathname, and it would be much to costly to calculate it at
that time.
What you can do is to execlude the whole log directory
(since its inode# won't change), either by the -e/-E option
or the chattr command.
Stelian.