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 <crobert...@gci.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<http://pages.cs.wisc.edu/%7Evshree/xfs.pdf> > > Chris > > > ------------------------------------------------------------------------------ > _______________________________________________ > BackupPC-users mailing list > BackupPC-users@lists.sourceforge.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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
