Linux LVM users
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox