All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Anthony W. Marino" <anthony@AWMObjects.com>
To: linux-lvm@sistina.com, Austin Gonyou <austin@coremetrics.com>
Subject: Re: [linux-lvm] LVM System
Date: Mon Mar  4 18:18:02 2002	[thread overview]
Message-ID: <auto-000020005385@front1.mail.megapathdsl.net> (raw)
In-Reply-To: <1015285989.24367.7.camel@UberGeek>

On Monday 04 March 2002 06:53 pm, Austin Gonyou wrote:
> On Mon, 2002-03-04 at 17:39, Steve Wray wrote:
> > I'd recommend ext3 with data journalling for sensitive
> > filesystems. Its slower than XFS but (seems to) scale better with
> > striping and large files. XFS performance (seems to) fall off
> > very rapidly as file size exceeds buffer size.
> >
> > XFS only journals metadata. So on event of a crash,
> > the filesystem structure will (likely) be sound, but theres
> > no guarantee that the data blocks will be uncorrupted!!!
> >
> > XFS is very nice tho, in that volumes and filesystems can
> > be grown with no downtime at all (without even unmounting).
> >
> > You might want to do some benchmarking before committing
> > to a build (thats recently saved my butt actually).
>
> I've only got a couple of things to say in the regard about XFS and
> performance Falling off.
>
> XFS's performance doesn't fall off in the respects you've spoken about.
> It's a misconception when using LVM, or evms, etc along with XFS.
>
> I ran into a similar issue, and was convinced it was XFS or LVM, etc.
> This is in the relation of using XFS and LVM, vs. XFS with no LVM, and
> then testing increasing filesizes with iozone.
>
> What I found was that dbench, and iozone both did not perform very well
> with respect to software raid or striping, but that in fact the
> filesystems themselves performed about 100% faster than without LVM
> striping or LVM Concat.
>
> So much faster that my database guys noticed the enourmous increase in
> speed on a test setup I created for them. One was using LVM, one was
> not, with XFS. The one which was NOT using LVM had a hardware stripe
> setup with write-back caching and adaptive read-ahead. The controller
> has 128MB pc100Dimm. Using a 3 drive RAID 0 hardware, vs 3 drives
> striped with LVM was an enourmous downgrade when benchmarking..but
> actual use, db inserts, file create, etc, ran >100% faster than with
> Hardware striping.
>
> I did the same test with Reiser and Ext2/3, none fared as well, but they
> all did better with LVM and striping than without.
>

What kernel release and XFS version are you using?
Anthony

> > > -----Original Message-----
> > > From: linux-lvm-admin@sistina.com
> >
> > [mailto:linux-lvm-admin@sistina.com]On
> >
> > > Behalf Of Anthony W. Marino
> > > Sent: Tuesday, 5 March 2002 10:39 a.m.
> > > To: linux-lvm@sistina.com
> > > Subject: [linux-lvm] LVM System
> > >
> > >
> > > Any thoughts or articles that would be usefull in determining the
> >
> > quality
> >
> > > on the following combination would be greatly appreciated:
> > >
> > > LVM 1.x
> > > 3Ware 7800 Raid Controller
> > > Maxtor 40GB harddrives
> > > XFS Journalling FS
> > > SuSE 2.4.18+ Linux
> > >
> > >
> > > Thank You,
> > > Anthony
> > >
> > > _______________________________________________
> > > linux-lvm mailing list
> > > linux-lvm@sistina.com
> > > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

  reply	other threads:[~2002-03-04 18:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-04 15:39 [linux-lvm] LVM System Anthony W. Marino
2002-03-04 15:51 ` lembark
2002-03-04 16:03   ` Anthony W. Marino
2002-03-04 16:00 ` Theo Van Dinter
2002-03-04 16:07   ` Anthony W. Marino
2002-03-04 16:11     ` Anthony W. Marino
2002-03-04 16:27     ` Theo Van Dinter
2002-03-04 16:39       ` Anthony W. Marino
2002-03-04 21:21         ` Theo Van Dinter
2002-03-04 21:36           ` Anthony W. Marino
2002-03-04 16:12   ` Anthony W. Marino
2002-03-04 17:39 ` Steve Wray
2002-03-04 17:50   ` Anthony W. Marino
2002-03-04 18:01     ` Steve Wray
2002-03-04 18:12       ` Austin Gonyou
2002-03-04 18:23         ` Steve Wray
2002-03-04 18:32           ` Austin Gonyou
2002-03-04 18:38             ` Steve Wray
2002-03-04 18:46             ` Goetz Bock
2002-03-04 19:58               ` Petro
2002-03-04 17:53   ` Austin Gonyou
2002-03-04 18:18     ` Anthony W. Marino [this message]
2002-03-04 18:39 ` Goetz Bock
2002-03-04 18:47   ` Anthony W. Marino
2002-03-04 18:51     ` Goetz Bock

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=auto-000020005385@front1.mail.megapathdsl.net \
    --to=anthony@awmobjects.com \
    --cc=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.