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.
If I am making a change, I'm going to a generation level upgrade, not 2%.
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.
there is no way to win an arguement on filesystems. this is a historical
fact :)
On Thu, Feb 28, 2008 at 4:47 PM, Les Mikesell <[EMAIL PROTECTED]> wrote:
> Adam Goryachev wrote:
> >
> >> there is the I/O caching. zfs caches checks of I/O and then reorders
> it
> >> to do a large, more-sequential write. it is also a copy-on-write
> >> filesystem which handles disk writes in a cache then reorder then write
> >> method also.
> >>
> >> also. tale a look
> >> http://www.opensolaris.org/jive/thread.jspa?threadID=11961&tstart=15
> >> <http://www.opensolaris.org/jive/thread.jspa?threadID=11961&tstart=15>
> >
> > So basically your comparison is not 'fair' because in one case you are
> > using write caching which will result in more lost data in some cases,
> > compared to no write caching. I don't know what mount options are
> > available for ext3, but I am pretty sure that there is an option to
> > enable similar write caching.
>
> I'm not sure if anyone cares about lost data on backuppc in the sense of
> losing what you would have lost anyway if the server had crashed a
> few seconds earlier. However, you do want the data to be consistent
> after recovery and the increased throughput has to persist beyond the
> initial cache fill.
>
> > I would be really interested in seeing the commands you are executing to
> > get these results (so other people can try and replicate them) and also
> > the results on reiserfs (v3, I wouldn't use v4 on a production server,
> > but perhaps v4 would also be interesting).
> >
> > PS, I've been a major fan of reiserfs for many years now, it seems to
> > work really well for most of my needs, which primarily involve large
> > maildir folders, backuppc, etc... I use it in most places as my
> > preferred choice. Though I'd like to see how it compares in actual tests
> > instead of just my 'gut feeling' that it is faster.
>
> I used and liked reiserfs for a long time too, but I think ext3 may be a
> close match if you set the right options. Directory indexing may be
> important to reduce the time it takes to identify if a filename is a new
> or existing entry as you make a new link.
>
> --
> Les Mikesell
> [EMAIL PROTECTED]
>
>
> -------------------------------------------------------------------------
> 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/
>
-------------------------------------------------------------------------
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/
