Post by Greg FreemyerPost by Marko Weber|8000Post by Stefan RingPost by Dave ChinnerPost by Marko Weber|8000sorry 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?
defaults,nobarrier,discard,logbsize=256k,noikeep
Post by Stefan RingPost by Dave ChinnerPost by Marko Weber|8000or is just "default" the best solution and xfs detect itself whats
best.
Post by Stefan RingPost by Dave ChinnerPost by Marko Weber|8000can 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
use
Post by Stefan RingMostly agreed, but using "discard" would be a no-brainer for me. I
suppose XFS does not automatically switch it on for non-rotational
storage.
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.
blkdev_issue_discard() is synchronous as well, which is a big
problem for something that needs to iterate (potentially) thousands
of regions for discard when a journal checkpoint completes....
Post by Greg FreemyerFor the SSD
itself that means the SSDs basically flush their write cache on
every trim call.
Oh, it's worse than that, usually. TRIM is one of the slowest
operations you can run on many drives, so it can take hundreds of
milliseconds to execute....
Post by Greg FreemyerI 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.
It was introduced into XFS as a checkbox feature. We resisted as
long as we could, but too many people were shouting at us that we
needed realtime discard because ext4 and btrfs had it. Of course,
all those people shouting for it realised that we were right in that
it sucked the moment they tried to use it and found that performance
was woeful. Not to mention that SSD trim implementations were so bad
that they caused random data corruption by trimming the wrong
regions, drives would simply hang randomly and in a couple of cases
too many trims too fast would brick them...
So, yeah, it was implement because lots of people demanded it, not
because it was a good idea.
Post by Greg FreemyerIn theory, SSDs that handle trim as a asynchronous
command are now available, but I don't know any specifics.
Requires SATA 3.1 for the queued TRIM, and I'm not sure that there
is any hardware out there that uses this end-to-end yet. And the
block layer can't make use of it yet, either...
Post by Greg FreemyerIn any case, fstrim works for almost all workloads and doesn't
have the potential continuous negative impact of -o discard.
Precisely my point - you just gave some more detail. :)
Cheers,
Dave.
--
Dave Chinner
***@fromorbit.com