thomat...@gmail.com wrote:
How dangerous is it to run xfs without write barriers?
http://oss.sgi.com/projects/xfs/faq.html#nulls
As long as your computer shuts down properly, sends a flush to the
drives, and the drives manage to clear their on-board cache before power
is removed or the chip
On Sat, Dec 20, 2008 at 6:22 AM, Chris Robertson crobert...@gci.net wrote:
dan wrote:
If the disk usage is the same as before the pool, the issue isnt
hardlinks not being maintained. I am not convinced that XFS is an
ideal filesystem. I'm sure it has it's merits, but I have lost data
Hi,
The server seems to be at a good level of performance now (1 hour and
45 minutes), thank you all for your help!
Retrospective, for people coming across this thread later and wanting
to fix backuppc xfs performance problems:
To fix this problem, I set the noatime and nodiratime options on the
I guess that updatedb thing reinforces my arguement about not seeing any
mixed load tests. ext3 handles these situations pretty good, maybe XFS does
not...
By the way, I read that EXT4 should allow for EXT3EXT4 upgrades. One(of
many) nice things about EXT4 is delayed writes which essentially
on 2008-12-19 10:56:44 +1100 [Re: [BackupPC-users]
backuppc 3.0.0: another xfs problem?]:
Jeffrey J. Kosowsky wrote:
I don't think that BackupPC_nightly checks for hard link dups between
the pc/ and pool/ directories.
I fully agree on that point.
I would advise that you confirm whether
If the disk usage is the same as before the pool, the issue isnt hardlinks
not being maintained. I am not convinced that XFS is an ideal filesystem.
I'm sure it has it's merits, but I have lost data on 3 filesystems ever,
FAT*, XFS and NTFS. I have never lost data on reiserfs3 or ext2,3.
dan wrote:
If the disk usage is the same as before the pool, the issue isnt
hardlinks not being maintained. I am not convinced that XFS is an
ideal filesystem. I'm sure it has it's merits, but I have lost data
on 3 filesystems ever, FAT*, XFS and NTFS. I have never lost data on
Hi,
I'm running BackupPC 3.0.0 under Ubuntu. I'm having problems similar
to the ones some people have had with 3.1.0 on XFS, but I also did
some other odd things before this started happening, so I want to
relate the whole scenario, in case I did something else to break it.
I accidentally
Hello Thomas,
Did the BackupPC_nightly jobs take 22 hours on the 17th as well? If
they didn't, I would suspect that since you restored the TopDir from a
tarball, that the hardlinking wasn't handled correctly in the tar
compression. BackupPC_nightly would have been re-establishing the
Thomas Smith wrote:
Hi,
No, it continues to take 22 hours or so each day.
-Thomas
How is your XFS volume mounted? Did you add the noatime and
nodiratime directives? If you have battery backed storage, I would
highly recommend using nobarrier as well
Paul Mantz wrote at about 10:19:45 -0800 on Thursday, December 18, 2008:
Hello Thomas,
Did the BackupPC_nightly jobs take 22 hours on the 17th as well? If
they didn't, I would suspect that since you restored the TopDir from a
tarball, that the hardlinking wasn't handled correctly in
Hi,
Adam Goryachev wrote on 2008-12-19 10:56:44 +1100 [Re: [BackupPC-users]
backuppc 3.0.0: another xfs problem?]:
Jeffrey J. Kosowsky wrote:
I don't think that BackupPC_nightly checks for hard link dups between
the pc/ and pool/ directories.
I fully agree on that point.
I would advise
Holger Parplies wrote at about 02:33:44 +0100 on Friday, December 19, 2008:
Hi,
Adam Goryachev wrote on 2008-12-19 10:56:44 +1100 [Re: [BackupPC-users]
backuppc 3.0.0: another xfs problem?]:
I would advise that you confirm whether or not your hard links were
restored properly
13 matches
Mail list logo
