xfs
[Top] [All Lists]

Re: Poor performance using discard

To: Linux fs XFS <xfs@xxxxxxxxxxx>
Subject: Re: Poor performance using discard
From: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Wed, 29 Feb 2012 10:38:03 +0000
In-reply-to: <20120229040819.GZ3592@dastard>
References: <1330469778.9688.7.camel@core24> <20120229012259.GW3592@dastard> <1330480826.9688.23.camel@core24> <20120229040819.GZ3592@dastard>
[ ... ]

> Same again - aparently when you system goes idle, it burns a CPU in
> user time, but stops doing that when IO is in progress.

>> This time, I ran a sync.  That should mean all of the discard
>> operations were completed...right?

> Well, it certainly is the case for XFS. I'm not sure what is
> happening with ext4 though.

>> If it makes a difference, when I get the i/o hang during the
>> xfs deletes, my entire system seems to hang.  It doesn't just
>> hang that particular mounted volumes' i/o.

> Any errors in dmesg?

I had hoped that the OP would take my suggestions and runs some
web search, because I was obviously suggesting that there the
behaviour he saw is expected and correct for XFS:

>>> * Learn how TRIM is specified, and thus why many people prefer
>>>   running periodically 'fstrim' which uses FITRIM to mounting
>>>   with 'discard'.

So let's cut it short: the TRIM command is specified to be
synchronous.

Therefore a sequence if TRIM operations will lock up the disk,
and usually as a result the host too. In addition to this, in
some implementations TRIM is faster and in some it is slower,
but again the main problem is that it is synchronous.

Therefore using 'discard' which uses TRIM is subject to exactly
the behaviour reported. But 'ext4' batches TRIMs, issuing them
out of the journal, while XFS probably issues them with every
deletion operation, so 'ext4' should be hit less, but the
difference should not be as large as reported.

I suspect then that recent 'ext4' ignores 'discard' precisely
because of the many reports of freezes they may have received.

An early discussion of the issue with TRIM:

http://www.spinics.net/lists/linux-fsdevel/msg23064.html

>From this report it seems that 'ext4' used to be "slow"
on 'discard' too:

https://patrick-nagel.net/blog/archives/337
 "I did it three times with and three times without the “discard”
  option, and then took the average of those three tries:
  Without “discard” option:
      Unpack: 1.21s
      Sync: 1.66s (= 172 MB/s)
      Delete: 0.47s
      Sync: 0.17s
  With “discard” option:
      Unpack: 1.18s
      Sync: 1.62s (= 176 MB/s)
      Delete: 0.48s
      Sync: 40.41s
  So, with “discard” on, deleting a big bunch of small files is 64
  times slower on my SSD. For those ~40 seconds any I/O is really
  slow, so that’s pretty much the time when you get a fresh cup of
  coffee, or waste time watching the mass storage activity LED."

Also the 'man' page for 'fstrim':

http://www.vdmeulen.net/cgi-bin/man/man2html?fstrim+8
 "-m, --minimum minimum-free-extent
    Minimum contiguous free range to discard, in bytes.
    (This value is internally rounded up to a multiple of the
    filesystem block size). Free ranges smaller than this will be
    ignored. By increasing this value, the fstrim operation will
    complete more quickly for filesystems with badly fragmented
    freespace, although not all blocks will be discarded. Default
    value is zero, discard every free block."

Note the "By increasing this value, the fstrim operation will
complete more quickly for filesystems with badly fragmented
freespace", which implies that FITRIM is also synchronous or slow
or both.

<Prev in Thread] Current Thread [Next in Thread>