All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin Gonyou <austin@coremetrics.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] JFS or XFS
Date: Thu Jan 15 22:38:01 2004	[thread overview]
Message-ID: <1074224135.2022.4.camel@localhost.localdomain> (raw)
In-Reply-To: <1074209631.19419.24.camel@david.internal.NorcrossGroup.com>

On Thu, 2004-01-15 at 17:33, Greg Freemyer wrote: 
> On Thu, 2004-01-15 at 18:22, neuron wrote:
> > reiserfs, guaranteed personally.  Especially on a mail server.
> 
> I agree, reiserfs was tuned for handling lots of small files.  Sounds
> perfect for a mail server.

Many tests prove this to be true as well. Search on google for what
Greg's saying. Lots of benches out there to see. 

[...]

> > Personally I haven't had any problems with XFS though, but I haven't
> used it that much.
> > 
> 
> If you go with XFS, stay away from anything older than 1.3.1.

Not to mention 1.3.x is when the xfslogd and xfsdatad were finally
implemented. I noted this in my prior email regarding tunable log
updates.


> The 1.2 and prior releases had this really nice feature that they
> ignored the sync command (and fsync I think).

It wasn't ignored, just not paid attention too as often it should've
been. ;)

> The end result is that with a power outage or kernel lockup you could
> lose lots of work.  I had one failure on a lightly used machine that
> had
> a whole days activities still sitting in the OS disk cache when the
> kernel locked up.

Depending on how often a system might sync()/fsync() this is true. As
well as any FS options you use for mounting XFS volumes regarding
log-buffers, io buffers, etc. 

> This is fixed in 1.3.1, 
> 
> Greg

Yes, much better now. Still, even with JFS or EXT3, as I noted before,
certain AbEnds will cause meta data to be lost. This is more a function
of hardware caching in a non-backed state, such as large cache buffers
of some drives 8MB drive cache, etc.  (i.e. no battery backed up cache)

-- 
Austin Gonyou <austin@coremetrics.com>
Coremetrics, Inc.

  parent reply	other threads:[~2004-01-15 22:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-15 18:19 [linux-lvm] JFS or XFS Rajesh Saxena
2004-01-15 18:24 ` neuron
2004-01-15 18:33   ` Austin Gonyou
2004-01-15 18:46   ` Greg Freemyer
2004-01-15 19:02     ` Spam
2004-01-20 16:15       ` Steven Lembark
2004-01-15 22:38     ` Austin Gonyou [this message]
2004-01-15 19:30 ` Rajesh Saxena
2004-01-16  8:57   ` Heinz Mauelshagen
2004-01-16 17:55     ` Rajesh Saxena
2004-01-16 19:43       ` Alasdair G Kergon
2004-01-16 19:48         ` Dan Sully
2004-01-16 20:06           ` Alasdair G Kergon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1074224135.2022.4.camel@localhost.localdomain \
    --to=austin@coremetrics.com \
    --cc=linux-lvm@sistina.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.