> On 24/05/2011 11:25 PM, Michael Stowe wrote:
>> I did a relatively short filesystem comparison when I moved my BackupPC
>> pool to another set of drives. The high level results:
>>
>> jfs, xfs: quick, stable
>> reiserfs: not stable
>> ext4: slow
>> ext3: very slow
>>
>> The "not stable" designation comes from power-off-during-write tests.
>> Other filesystems generally handled this gracefully, but reiserfs
>> corrupted the entire tree, and the recovery tools didn't get it back
>> intact.
>
> Just a couple of my own personal comments on reiserfs:
> 1) It does usually handle random power-offs on both general servers and
> backuppc based servers.
"Usually" doesn't really do it for me.
The problem seems to be in the structure of the trees and the rebuild tree
routines, which just grabs every block that looks like they're reiserfs
tree blocks.
> 2) It does sometimes have problems resurrecting the filesystem when it
> has been corrupted, I did lose *one* home directory out of 400 once upon
> a time.... (about 9 years ago...)
Like I said, a filesystem that loses data *sometimes* doesn't really make
it to the top of the list, in favor of filesystems that ... don't have
this problem.
> 3) I've used reiserfs on both file servers and backuppc servers for
> quite a long time (and also desktops until very recently) with no
> problems that I wouldn't expect from any other FS. One backuppc server I
> used it with never expired any backup, and did daily backups of about 5
> servers with a total of 700G data. This was working fine for over 5
> years (turned off recently due to company issues, not technical).
There are plenty of things that run perfectly well when unstressed. For
example, 32-bit zfs runs *perfectly* well, unless you try to rsync the
whole filesystem... in which case it panics the kernel.
> I would expect that any FS will *sometimes* have a problem fixing it's
> FS after a power loss unless you use journally on the data as well as
> the FS info. Perhaps in your testing you either didn't enable the
> correct journalling options, or found that particular corner case.
> Perhaps next time it happens jfs/xfs might hit their corner cases.
This doesn't ring true nor does it match the results of my testing. I
didn't tune any file systems. xfs and jfs were resilient to simple power
fail situations, reiserfs was not. You can speculate that xfs and jfs may
contain the same flaws but some kind of blind luck kept them working
properly, but it seems *really* unlikely.
Further, simply "running" a filesystem is not the same as testing and
recovering it. It's certainly possible to have run a FAT filesystem under
Windows 3.1 for 20 years. This doesn't make it a robust choice.
> My understanding of reiserfs development is that it is stable, and being
> in the linux tree, is maintained.
Stable development and being a stable filesystem aren't the same thing,
naturally.
> However, while I liked reiserfs a lot, I've recently found that support
> for it is declining (can't even select it as a FS option when installing
> some new OS's), and that other FS's offer a lot of the same performance
> features, thus making reiserfs somewhat obsolete. It would be nice to
> see some real performance benchmarks with reiserfs and jfx/xfs but I
> can't really be bothered, and probably neither is anyone else.
For my part, I didn't bother because it didn't pass the "stable" hurdle.
It doesn't matter how fast it is if it can't preserve the data intact.
Frankly, it was the only FS that didn't, which included ext3 -- again,
I'll stress the fact that I actually tested them, I didn't just trust that
everything was intact.
> I expect
> reiserfs will eventually go away, and as such I'm migrating away from it
> as my systems are retired/etc (but it will be in use for a long time as
> it isn't easy to format and restore or migrate large amounts of data...)
> I don't mean to disparage xfs/jfs or any testing anybody has done, just
> wanted to share my personal experiences.
Since you don't appear to be arguing that people actually use reiserfs,
you're speculating that xfs/jfs contain flaws without any apparent
evidence, and your personal experiences don't appear to include testing,
I'm not really sure where you're going with this.
Due to time constraints, I didn't do a great many trials, but I'll give
you an idea of what my testing entailed:
On a 7-drive array (5+2 RAID), make a new filesytem, and point the
BackupPC pool at it.
A script runs that uses X10 to physically power down the box once it
senses the presence of a test file. This script is used for both the
initial backup and the link phase, both of which are restarted once during
the trial. (This script was originally timed to power down one hour into
the backup, but since the backups ran at different speeds on the
filesystems, it seemed likely that the backups would be at different
points. To avoid corner cases, they were powered down while backing up
the exact same file.)
The pool is then compared (via rsync) to the test box; everything should
be identical.
xfs/jfs performed flawlessly, as did ext4, and ext3
reiserfs suggested fsck and --rebuild-tree on one run, lost a directory on
another run, and had crosslinked files on another. (Another few runs had
no problems.)
After all this, I ran time trials on the xfs/jfs/ext4/ext3 for backup and
linking. I didn't bother with reiserfs, for the above reasons.
The differences between xfs and jfs weren't significant, but ext4/3 was
significantly slower, apparently due to the link. (Were I to do it again,
I'd distinguish between the backup and the link phases, which I did not.)
> Regards,
> Adam
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
