All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: ext4 development <linux-ext4@vger.kernel.org>
Cc: Ric Wheeler <rwheeler@redhat.com>
Subject: Re: Do we need dump for ext4?
Date: Fri, 29 Aug 2008 07:36:16 -0500	[thread overview]
Message-ID: <48B7ED40.6020508@redhat.com> (raw)
In-Reply-To: <48B6BD02.3080307@redhat.com>

Eric Sandeen wrote:
> I was talking to Ric about dump benchmarks, and he was of the impression
> that dump may not be used that often anymore, at least in the
> enterprise.  (Ric, hope I'm paraphrasing correctly)
> 
> Undaunted :) I ran off and tested an artificial backup scenario:
> 
> * Untar a kernel tree into 128 different top level dirs
> * Make a level 0 backup
> * Untar a kernel tree into 128 MORE different top level dirs
> * Make a level 1 backup
> 
> 128 kernel trees uses about 6.5M inodes, and about 80G of space.
> 
> I tested ext3 with dump; ext4 with tar, and xfs with xfsdump.
> 
> for ext3:
> dump -1 -u -f $DUMPDIR/dump1 $DATADIR
> 
> for ext4:
> tar --atime-preserve --xattr --after-date=$DUMPDIR/dump0.tar -cf
> $DUMPDIR/dump1.tar $DATADIR
> 
> for xfs:
> xfsdump -F -l 1 -f $DUMPDIR/dump0 $DATADIR
> 
> DUMPDIR and DATADIR were 2 partitions on the same (fast hardware) lun.
> 
> Results:

at Ric & hch's  request here is tar on the other fs's as well, re-sorted
 by level 0 dump time.  I put acp into the mix as well.

Oh, and this time I remembered to set the elevator to something sane
(noop) for this storage, oops (was cfq last time)

Also, this time the dup/tar/acp was written to /dev/null rather than
another filesystem.  Interesting how routing to /dev/null alone changed
the ranking quite a bit.

		level0	level1
		======	======
ext4-acp	12m22s	------
ext3-acp	14m11s	------
ext4-tar	18m24s	34m56s
ext3-dump	19m30s	35m30s
xfs-dump        20m07s	40m24s
ext3-tar	21m16s	42m41s
xfs-tar		21m19s	46m13s
xfs-acp		29m38s	------

-Eric

  parent reply	other threads:[~2008-08-29 12:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-28 14:58 Do we need dump for ext4? Eric Sandeen
2008-08-28 18:48 ` Theodore Tso
2008-08-28 19:03   ` Ric Wheeler
2008-08-28 20:04     ` Andreas Dilger
2008-08-28 20:35       ` Theodore Tso
2008-08-28 22:23         ` Andreas Dilger
2008-08-28 22:34           ` Theodore Tso
2008-08-28 23:14             ` Andreas Dilger
2008-08-28 19:13   ` Eric Sandeen
2008-08-29 12:36 ` Eric Sandeen [this message]
2008-08-29 14:17   ` Theodore Tso
2008-08-29 18:14     ` Eric Sandeen
2008-08-31  2:43   ` Andreas Dilger
2008-09-02 15:52     ` Eric Sandeen

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=48B7ED40.6020508@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=rwheeler@redhat.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.