Hi folks,
If you are concerned about dumping live filesystem with Linux kernel
2.4, you might be interested in this: SGI has released an updated
anaconda installer CD for Red Hat 7.1 with XFS journaled filesystem
support. You load the installer CD first, which includes only the RPMs
necessary for XFS support, and then you will need the regular Red Hat
7.1 CDs to complete the installation:
ftp://linux-xfs.sgi.com/projects/xfs/download/
With XFS you have the option of using xfsdump for your backups on
Linux--AFAIK this should work with amanda, but I have not tested it and
YMMV. According to my discussions with Eric Sandeen at SGI, xfsdump
does not look at the "on-disk metadata structures directly," so it would
not be subject to the problem which affects ext2fs and Linux dump. I am
forwarding Eric's response to a couple questions that I had about it.
Now if only amrecover would work with xfsdump, I would be in heaven :-)
-------- Original Message --------
Subject: Re: SGI's XFS: ready for production use?
Date: Fri, 11 May 2001 11:39:19 -0500
From: Eric Sandeen <[EMAIL PROTECTED]>
To: Jonathan Dill <[EMAIL PROTECTED]>
CC: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Jonathan Dill wrote:
>
> Hi Eric,
>
> Are there plans to keep up with new releases of Red Hat eg. release a
> new anaconda disk as new versions come out? I have a mostly SGI IRIX
> shop with a growing Linux population, so it seems somehow attractive to
> be able to use XFS as a standard--It could mean good things for
> consistent, automated backups, and being able to toss filesystems around
> between IRIX and Linux. I would consider adopting this as a standard,
> but I want to make sure that it will be updated and not a dead end.
In terms of Red Hat integration, we don't really have an official
guarantee that we'll keep up with the Red Hat releases. However, I
expect that we will, unofficially if not officially. There are enough
people interested in this inside and outside of SGI that I think this
will continue. I have a personal interest in continuing.
Of course, if Red Hat and/or Linus picks up XFS, that would be a good
thing too, and we're trying to facilitate both of those things.
As far as SGI's commitment to XFS on Linux, while I can't speak for the
company, I see no signs of that commitment waning. We need XFS on Linux
for upcoming products, and for our customers.
And of course, the source is out there, so that's a certain level of
guarantee that XFS will "be around."
See also the "Long Term Commitment..." thread at
http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/threads.html
> Also, there has been a lot of chatter lately about the problems with
> Linux dump and ext2fs corruption. Is it true that XFS with the xfsdump
> tools ought to be free from these sorts of buffer cache issues? Or is
> it safest on Linux to stick with tools like gnutar which access the FS
> at a higher level?
Here's the scoop from Nathan Scott, our userspace guru:
> Yes, I also read this thread - it was quite interesting.
>
> Though it wasn't explicitly spelt out, I think the problem
> that was being refered to with dump (not xfsdump) is that
> it looks at the on-disk metadata structures (via libext2fs)
> to figure out what needs dumping, etc. tar, et al. use the
> standard system call interfaces for traversing metadata and
> obtaining file data, so aren't exposed to the problems
> associated with dump-on-a-mounted-filesystem.
>
> xfsdump uses an xfs-specific ioctl (bulkstat) to walk the
> filesystem inodes, and doesn't refer directly to the on-disk
> data structures either, so it should be as safe as tar.
HTH,
-Eric
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
[EMAIL PROTECTED] SGI, Inc.
