-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dan wrote: > I tend to agree that reiserfs doesn't add enough performance to deviate > from ext3. some operations are much much faster but not many. In MOST > situations, the only thing reiserfs is good for is high numbers on a > benchmark. In the real world, on most systems, it doesn't do much. I > think reiserfs came to fame specifically because of gentoo linux because > it gave a noticable improvement when working with portage. in ubuntu, > reiserfs is just another descent filesystem.
Well, I guess that is what we would like to quantify, how much better or worse is it specifically in relation to backuppc style workload? > If I am making a change, I'm going to a generation level upgrade, not 2%. Sometimes you need every little extra you can get, even 2% can be a help.... Though you are right, 2% would generally just be called testing differences... > As far as data loss because of a crash or power outage before cache > write, I would suggest you run you server like a server to avoid a > system crash. most system crashes are a result of the desktop > environments run, so dont run a desktop environment on a server or run a > low resource environment like fluxbox and only when needed, not let it > just sit there. Also, put your system on a battery backup! keep in > mind that this is not in-production data, meaning a failed backup can be > re-run though that should be very uncommon. I have been admining unix > systems for years and have never had a crash that cause un-recoverable > dataloss because I run the services I need and no more, and have > everything on UPS and backed up properly. > > as far as "So basically your comparison is not 'fair' because....", any > and all hard disk activity goes through a cache. a raid controller has > cache and a hard disk has cache. zfs is just using main memory for it's > caching and it should not really be called 'caching' as it is really > just a sort mechanism to allow reordered operations. In fact, faster > disk performance leads to LESS dataloss because more of the writes will > be done before the crash. I agree with all that, but regardless of UPS or whatever else, there is always that time when things will go wrong. BTW, I might be approaching all of these discussions from a slightly different angle to most people. While a couple of the backuppc servers I am responsible for are simply backups of other systems, and if you lost ALL the data on the backup server it isn't a big deal, just do another full backup and continue. However, there is one system I look after where we never remove any incremental or full backup. It has been running for close to two years. If we lost all of that data, then we would be very upset to say the least. Hopefully, in ten years time, we will still be able to go back to any day over the last ten years and retrieve a file as it existed on that day. > there is no way to win an arguement on filesystems. this is a > historical fact :) Winning isn't the fun, finding out how to squeeze an extra 10% performance from existing hardware is :) My own backup server is running on a PIV 1.8GHz with 768M RAM. Just in case this goes around in a loop forever, I'll do my best to refrain from further comments until someone can come up with a specific set of commands to replicate backuppc workload.... Regards, Adam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHx4lkGyoxogrTyiURAq73AJ9Q7Gq/nBsYd0dQt0VzcwMrhNX++wCfYuW6 CHLB9E6zjHUGaMzgM+8uJkQ= =T+Jx -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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/ _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
