From: Dave Chinner <david@fromorbit.com>
To: Spelic <spelic@shiftmail.org>
Cc: xfs@oss.sgi.com, linux-ext4@vger.kernel.org,
device-mapper development <dm-devel@redhat.com>
Subject: Re: Ext4 and xfs problems in dm-thin on allocation and discard
Date: Tue, 19 Jun 2012 11:57:45 +1000 [thread overview]
Message-ID: <20120619015745.GJ25389@dastard> (raw)
In-Reply-To: <4FDF9EBE.2030809@shiftmail.org>
On Mon, Jun 18, 2012 at 11:33:50PM +0200, Spelic wrote:
> Hello all
> I am doing some testing of dm-thin on kernel 3.4.2 and latest lvm
> from source (the rest is Ubuntu Precise 12.04).
> There are a few problems with ext4 and (different ones with) xfs
>
> I am doing this:
> dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync
> lvs
> rm zeroes #optional
> dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync #again
> lvs
> rm zeroes #optional
> ...
> dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync #again
> lvs
> rm zeroes
> fstrim /mnt/mountpoint
> lvs
[snip ext4 problems]
> On xfs there is a different problem.
> Xfs apparently correctly re-uses the same blocks so that after the
> first write at 140MB/sec, subsequent overwrites of the same file are
> at full speed such as 350MB/sec (same speed as with non-thin lvm),
> and also you don't see space occupation going up at every iteration
> of dd, either with or without rm in-between the dd's. [ok actually
> now retrying it needed 3 rewrites to stabilize allocation...
> probably an AG count thing.]
That's just a characteristic of the allocation algorithm. It's not
something that you see in day-to-day operation of the filesystem,
though, because you rarely remove and rewrite a file like this
repeatedly. So in the real world, performance will be more like ext4
when you are running workloads where you actually store data for
longer than a millisecond...
Expect that the 140MB/s number is the normal performance case,
because as soon as you take a snapshot, the overwrite requires new
blocks to be allocated in dm-thinp. You don't get thinp for nothing
- it has an associated performance cost as you are now finding
out....
> However the problem with XFS is that discard doesn't appear to work.
> Fstrim doesn't work, and neither does "mount -o discard ... + rm
> zeroes" . There is apparently no way to drop the allocated blocks,
> as seen from lvs. This is in contrast to what it is written here
> http://xfs.org/index.php/FITRIM/discard which declare fstrim and
> mount -o discard to be working.
I don't see why it wouldnt be if the underlying device supports it.
Have you looked at a block trace or an xfs event trace to see if
discards are being issued by XFS?
Are you getting messages like:
XFS: (dev) discard failed for extent [0x123,4096], error -5
in dmesg, or is fstrim seeing errors returned from the trim ioctl?
> Please note that since I am above MD raid5 (I believe this is the
> reason), the passdown of discards does not work, as my dmesg says:
> [160508.497879] device-mapper: thin: Discard unsupported by data
> device (dm-1): Disabling discard passdown.
> but AFAIU, unless there is a thinp bug, this should not affect the
> unmapping of thin blocks by fstrimming xfs... and in fact ext4 is
> able to do that.
Does ext4 report that same error?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Spelic <spelic@shiftmail.org>
Cc: device-mapper development <dm-devel@redhat.com>,
linux-ext4@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: Ext4 and xfs problems in dm-thin on allocation and discard
Date: Tue, 19 Jun 2012 11:57:45 +1000 [thread overview]
Message-ID: <20120619015745.GJ25389@dastard> (raw)
In-Reply-To: <4FDF9EBE.2030809@shiftmail.org>
On Mon, Jun 18, 2012 at 11:33:50PM +0200, Spelic wrote:
> Hello all
> I am doing some testing of dm-thin on kernel 3.4.2 and latest lvm
> from source (the rest is Ubuntu Precise 12.04).
> There are a few problems with ext4 and (different ones with) xfs
>
> I am doing this:
> dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync
> lvs
> rm zeroes #optional
> dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync #again
> lvs
> rm zeroes #optional
> ...
> dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync #again
> lvs
> rm zeroes
> fstrim /mnt/mountpoint
> lvs
[snip ext4 problems]
> On xfs there is a different problem.
> Xfs apparently correctly re-uses the same blocks so that after the
> first write at 140MB/sec, subsequent overwrites of the same file are
> at full speed such as 350MB/sec (same speed as with non-thin lvm),
> and also you don't see space occupation going up at every iteration
> of dd, either with or without rm in-between the dd's. [ok actually
> now retrying it needed 3 rewrites to stabilize allocation...
> probably an AG count thing.]
That's just a characteristic of the allocation algorithm. It's not
something that you see in day-to-day operation of the filesystem,
though, because you rarely remove and rewrite a file like this
repeatedly. So in the real world, performance will be more like ext4
when you are running workloads where you actually store data for
longer than a millisecond...
Expect that the 140MB/s number is the normal performance case,
because as soon as you take a snapshot, the overwrite requires new
blocks to be allocated in dm-thinp. You don't get thinp for nothing
- it has an associated performance cost as you are now finding
out....
> However the problem with XFS is that discard doesn't appear to work.
> Fstrim doesn't work, and neither does "mount -o discard ... + rm
> zeroes" . There is apparently no way to drop the allocated blocks,
> as seen from lvs. This is in contrast to what it is written here
> http://xfs.org/index.php/FITRIM/discard which declare fstrim and
> mount -o discard to be working.
I don't see why it wouldnt be if the underlying device supports it.
Have you looked at a block trace or an xfs event trace to see if
discards are being issued by XFS?
Are you getting messages like:
XFS: (dev) discard failed for extent [0x123,4096], error -5
in dmesg, or is fstrim seeing errors returned from the trim ioctl?
> Please note that since I am above MD raid5 (I believe this is the
> reason), the passdown of discards does not work, as my dmesg says:
> [160508.497879] device-mapper: thin: Discard unsupported by data
> device (dm-1): Disabling discard passdown.
> but AFAIU, unless there is a thinp bug, this should not affect the
> unmapping of thin blocks by fstrimming xfs... and in fact ext4 is
> able to do that.
Does ext4 report that same error?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-06-19 1:57 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-18 21:33 Ext4 and xfs problems in dm-thin on allocation and discard Spelic
2012-06-18 21:33 ` Spelic
2012-06-19 1:57 ` Dave Chinner [this message]
2012-06-19 1:57 ` Dave Chinner
2012-06-19 3:12 ` Mike Snitzer
2012-06-19 3:12 ` Mike Snitzer
2012-06-19 6:32 ` Lukáš Czerner
2012-06-19 6:32 ` Lukáš Czerner
2012-06-19 11:29 ` Spelic
2012-06-19 11:29 ` Spelic
2012-06-19 12:20 ` Lukáš Czerner
2012-06-19 12:20 ` Lukáš Czerner
2012-06-19 13:34 ` Mike Snitzer
2012-06-19 13:34 ` Mike Snitzer
2012-06-19 13:16 ` Mike Snitzer
2012-06-19 13:16 ` Mike Snitzer
2012-06-19 13:25 ` Lukáš Czerner
2012-06-19 13:25 ` Lukáš Czerner
2012-06-19 13:30 ` Mike Snitzer
2012-06-19 13:30 ` Mike Snitzer
2012-06-19 13:52 ` Spelic
2012-06-19 13:52 ` Spelic
2012-06-19 14:05 ` Eric Sandeen
2012-06-19 14:05 ` Eric Sandeen
2012-06-19 14:44 ` Mike Snitzer
2012-06-19 14:44 ` Mike Snitzer
2012-06-19 18:48 ` Mike Snitzer
2012-06-19 18:48 ` Mike Snitzer
2012-06-19 20:06 ` Dave Chinner
2012-06-19 20:06 ` Dave Chinner
2012-06-19 20:21 ` Ted Ts'o
2012-06-19 20:21 ` Ted Ts'o
2012-06-19 20:39 ` Dave Chinner
2012-06-19 20:39 ` Dave Chinner
2012-06-20 9:01 ` Christoph Hellwig
2012-06-20 9:01 ` Christoph Hellwig
2012-06-19 21:37 ` Spelic
2012-06-19 21:37 ` Spelic
2012-06-19 23:12 ` Dave Chinner
2012-06-19 23:12 ` Dave Chinner
2012-06-20 12:11 ` Spelic
2012-06-20 12:11 ` Spelic
2012-06-20 22:53 ` Dave Chinner
2012-06-20 22:53 ` Dave Chinner
2012-06-21 17:47 ` Mike Snitzer
2012-06-21 17:47 ` Mike Snitzer
2012-06-21 23:29 ` Dave Chinner
2012-06-21 23:29 ` Dave Chinner
2012-07-01 14:53 ` Paolo Bonzini
2012-07-01 14:53 ` Paolo Bonzini
2012-07-02 13:00 ` Mike Snitzer
2012-07-02 13:00 ` Mike Snitzer
2012-07-02 13:15 ` Paolo Bonzini
2012-07-02 13:15 ` Paolo Bonzini
2012-06-19 14:09 ` Lukáš Czerner
2012-06-19 14:09 ` Lukáš Czerner
2012-06-19 14:19 ` Ted Ts'o
2012-06-19 14:19 ` Ted Ts'o
2012-06-19 14:23 ` Eric Sandeen
2012-06-19 14:23 ` Eric Sandeen
2012-06-19 14:37 ` Lukáš Czerner
2012-06-19 14:37 ` Lukáš Czerner
2012-06-19 14:43 ` [dm-devel] " Alasdair G Kergon
2012-06-19 14:43 ` Alasdair G Kergon
2012-06-19 15:28 ` Mike Snitzer
2012-06-19 15:28 ` Mike Snitzer
2012-06-19 16:03 ` [dm-devel] " Alasdair G Kergon
2012-06-19 16:03 ` Alasdair G Kergon
2012-06-19 19:58 ` Ted Ts'o
2012-06-19 19:58 ` Ted Ts'o
2012-06-19 20:44 ` Mike Snitzer
2012-06-19 20:44 ` Mike Snitzer
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=20120619015745.GJ25389@dastard \
--to=david@fromorbit.com \
--cc=dm-devel@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=spelic@shiftmail.org \
--cc=xfs@oss.sgi.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.