On Feb 11, 2008 11:13 AM, Chun Kit Hui <huichunkit < at > gm...> wrote:
Dear Bruno,
You mean that xfs will save ACLs and extended data together with the file
instead of meta-data? And without special configuration, Bacula will backup
all these "meta-data" together with the files?
Let me have a trial later today.
Cheers,
Jacky
On Feb 11, 2008 10:02 PM, Bruno Friedmann <bruno < at > io...> wrote:
Chun Kit Hui wrote:
Dear Bruno,
But how does the use of XFS help solve the problem on backup of extended
attributes using bacula?
Jacky
XFS as this attribute inside and are perfectly saved by bacula. So they
are restored also as needed.
You should give it a try on a xfs partition to see if you get saved and
restored all you need.
--
Bruno Friedmann bruno < at > io...
Ioda-Net Sàrl -
http://www.ioda-net.ch
2830 Vellerat - Switzerland
Tél : ++41 32 435 7171
Fax : ++41 32 435 7172
gsm : ++41 78 802 6760
C'est Facile et Cool d'Évoluer en ligne :
http://www.cfcel.com
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users
interesting suggestion about xfs, but according to the xfs faq:
http://oss.sgi.com/projects/xfs/faq.html#backingupxfs
'''
Q: How can I backup a XFS filesystem and ACLs?
You can backup a XFS filesystem with utilities like xfsdump(
and
standard tar(1) for standard files. If you want to backup ACLs you
will need to use xfsdump, this is the only tool at the moment that
supports backing up extended attributes. xfsdump can also be
integrated with amanda(
.
'''
comments/clarifications about this point would be good.
on the current state of linux filesystems:
The xfs linux port and support/development going forward is somewhat
doubtful. SGI has been paying the devs to do the port, but they're
not the healthiest of companies these days. Other people could pick
up the ball, but there's no guarantee of that of course.
Yes, xfs is in the kernel so it is maintained by the kernel devs, but
there are outstanding issues which even the xfs port team says you may
not want to use xfs due to. There's a huge compatability layer (for
instance), basically to interface xfs to the linux kernel (instead of
IRIX). And there are some issues with data corruption with journal
playback/fsck under certain circumstances.
However, some of these issues have been fixed fairly recently, so you
need to check your kernel version/patches etc. The xfs faq linked
above hits upon many of the issues, some of them having been addresses
only withing the last 6-12 months.
reiserfs v3/4 is in a similar boat. development is pretty much
suspended, and was never terribly popular with the core kernel devs.
ext3 _really_ seems to be the safest bet these days, with ext4 in the
future. Wasn't my first choice in filesystems for linux either, but
it by far makes the most sense for today and going forward. It's just
plain supported the best by far and has a very solid history.
I guess the point I'm trying to make is linux has multiple filesystems
for a reason: they're not all perfect.
--
Noah Dain
"The beatings will continue, until morale improves" - the Management
Re: [Bacula-users] btape fill: that last block on the first tape ok or not? From: K. M. Peterson
Attachments: Message as HTML
On Mon, Feb 11, 2008 at 12:49 PM, Dan Langille <dan < at > la...> wrote:
K. M. Peterson wrote:
...
Error reading block: ERR=block.c:1008 Read zero bytes at 1180:0 on
device "Drive-1" (/dev/nst0).
Have you tried a different tape as the second tape?
Hi,
No, I haven't. I only have two DLT-S4 tapes at the moment, but I'll swap
them and rerun the 'fill' tonight.
Also, the compression question was more along the lines of: with a volume
capacity of 812GB, and a write speed of 45MB/sec I presume that the drive
isn't compressing the data. This would either be because the drive isn't
set properly (although tapeinfo says DataCompEnabled: yes) or because fill
writes really random data that isn't compressible. So I was wondering which
of these explanations is more likely.
I also played with the blocksize directives. tapeinfo says that the drive
can write 16MB blocks; that would presumably be the fastest way to write to
tape. However, btape says that's too big a blocksize so I'm wondering
whether there is an issue with the size that the kernel/device is set to
use.
But really I'd be happy if btape - fill doesn't throw an error, and I'd
still like any suggestions of things to try.
Thanks!
--
Dan Langille
BSDCan - The Technical BSD Conference :
http://www.bsdcan.org/
PGCon - The PostgreSQL Conference:
http://www.pgcon.org/
is to use a
