On August 29, 2014 4:37:38 AM EDT, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>On Fri, Aug 29, 2014 at 08:31:43AM +0200, Stefan Ring wrote:
>> On Thu, Aug 28, 2014 at 1:07 AM, Dave Chinner <david@xxxxxxxxxxxxx>
>> > On Wed, Aug 27, 2014 at 12:14:21PM +0200, Marko Weber|8000 wrote:
>> >> sorry dave and all other,
>> >> can you guys recommend me the most stable / best mount options for
>> >> my new server with ssdÂs and XFS filesystem?
>> >> at moment i would set:
>> >> or is just "default" the best solution and xfs detect itself whats
>> >> can you guide me a bit?
>> >> as eleavtor i set elevator=noop
>> >> i setup disks with linux softraid raid1. On top of the raid is LVM
>> >> (for some data partations).
>> >> would be nice to hear some tipps from you
>> > Unless you have specific requirements or have the knowledge to
>> > understand how the different options affect behaviour, then just
>> > the defaults.
>> Mostly agreed, but using "discard" would be a no-brainer for me. I
>> suppose XFS does not automatically switch it on for non-rotational
>Yup, you're not using your brain. :P
>mount -o discard *sucks* on so many levels it is not funny. I don't
>recommend that anybody *ever* use it, on XFS, ext4 or btrfs. Just
>use fstrim if you ever need to clean up a SSD.
In particular trim is a synchronous command in many SSDs, I don't know about
the impact on the kernel block stack. For the SSD itself that means the SSDs
basically flush their write cache on every trim call.
I often tell people to do performance testing with and without it and report
back to me if they see no degradation caused by -o discard. To date no one has
ever reported back. I think -o discard should have never been introduced and
certainly not 5 years ago. In theory, SSDs that handle trim as a asynchronous
command are now available, but I don't know any specifics.
In any case, fstrim works for almost all workloads and doesn't have the
potential continuous negative impact of -o discard.
Sent from my Android phone with K-9 Mail. Please excuse my brevity.