Re: [BackupPC-users] backuppc 3.0.0: another xfs problem?

I'm pretty excited (as exited as one gets about filesystems) with the nexgen filesystems that are progressing. btfs looks to be a very good concept and I hope that translated to a very good filesystem.

Im glad to hear that reiserfs4 is continuing, though I think they may want to change the name and distance the project from Hanns' name. I really believe that reiserfs3 was the best of the current generation filesystems. I used to use gentoo when I jumped ship on redhat and rpm hell. reiserfs was always vastly superior on gentoo as it's small file handling is very very good and gentoo/compiling from source benefitted from that. I have not really tried reiserfs3 with backuppc as I have been on ext3 and happy enough that ext3 is reliable and fast enough.

On Mon, Dec 22, 2008 at 4:14 PM, Chris Robertson <crobertson AT gci DOT net> wrote:

dan wrote:
> 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...

Write barriers really harmed XFS performance on my setup (16 Seagate
ES.2 spindles attached to an Adaptec 51645 utilizing hardware RAID6).
iostat was showing a peak of 400 tps with barriers. Mounting nobarrrier
raised that limit to to over 20,000. Obviously your mileage may vary.
Two interesting data points to note, it appears that LVM doesn't support
barriers
(http://hightechsorcery.com/2008/06/linux-write-barriers-write-caching-lvm-and-filesystems),
and ext3 (and ext4) don't use barriers by default
(http://lwn.net/Articles/282958/). The design allows for this without
as much risk as might be expected (http://lwn.net/Articles/283168/).

Back to XFS, allocation groups, unless specified at file system creation
are calculated on file system size, and can have a great effect on
performance when multiple threads are contenting for FS access.
Changing the journal size can also have an effect on performance, but
again, this is only possible at creation. Changing the number and size
of log buffers is a mount time modification, and might also have a
decent effect on performance. The kernel documentation has more
information on this.

>
> By the way, I read that EXT4 should allow for EXT3>EXT4 upgrades.

Same thing for btrfs. Neat stuff.

> One(of many) nice things about EXT4 is delayed writes which
> essentially means write re-ordering to mask/reduce I/O bottlenecks.

Which XFS already has... But they are affected by write barriers.

> Hopefully EXT4 will become stable pretty soon!

Agreed. As a side note, development on Reiser4 is ongoing:
http://marc.info/?l=reiserfs-devel&r=1&w=2

Finally, if you are sleeping too well at night because you think your
data is safe, I have a couple of papers your might be interested in that
I stumbled across while fact checking:

Model-Based Failure Analysis of Journaling File Systems (covers ext3,
Reiserfs, and JFS):
http://www.cs.wisc.edu/adsl/Publications/sfa-dsn05.pdf

Failure Analysis of SGI XFS File System:
http://pages.cs.wisc.edu/~vshree/xfs.pdf

Chris

------------------------------------------------------------------------------
_______________________________________________
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/

------------------------------------------------------------------------------

_______________________________________________
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/