On 10/7/05, Alexander Fisher <alexjfisher@xxxxxxxxx> wrote:
> On 10/6/05, Nathan Scott <nathans@xxxxxxx> wrote:
> > On Thu, Oct 06, 2005 at 06:26:29PM +0100, Alexander Fisher wrote:
> SNIP
> > > Given these errors, I'm not sure that I want to rely on the backups
> > > taken with xfsdump. Can they be ignored?!
> >
> > If its a readonly snapshot, yes they can. (are device mapper
> > snapshots always readonly? I dunno) -- these look like the
> > sorts of errors that would come from XFS not processing the
> > unlinked list, which is what we do for a snapshot (XFS assumes
> > it is readonly).
>
> As far as I can see all LVM2 snapshots are read-write (at least I
> can't find an option for lvcreate to make one read-only).
>
> > > I was under the impression that xfs_freeze shouldn't be used anymore
> > > since it will deadlock (which it does). I'm using Debian Sarge with
> >
> > Right. Its arguably a block layer (bdev_freeze, outside XFS) bug,
> > noones had time/motivation to go fix it up.
> >
> > > Other than mounting filesystems read-only before snapshoting (which
> > > isn't practical), is there anything else I can do?
> >
> > As long as the snapshot is mounted readonly, those check errors
> > are fine. If we want writable snapshots, we have some work to
> > do in XFS to ensure the log is left dirty on the snapshot, so that
> > when its mounted we process the unlinked list... its mainly an
> > issue of not knowing whether the snapshot target is ro/rw.
>
> So, read-write snapshots are fine for backups with xfsdump as long as
> I mount them read-only?
>
> Thanks,
> Alex
>
Hi again.
I've mounted my snapshots readonly, but I occasionally get warnings
from xfsdump during the backups. I get two different types of
warning.
xfsdump: WARNING: failed to get bulkstat information for inode 10485897
and
xfsdump: WARNING: could not stat dirent .viminfo ino 10485896: No such
file or directory: using null generation count in directory entry
What's causing these? Can they be ignored?
Thanks,
Alex
|