On Fri, Aug 29, 2014 at 07:26:59AM -0400, Greg Freemyer wrote: > > > 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> > >wrote: > >> > 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: > >defaults,nobarrier,discard,logbsize=256k,noikeep > >> >> or is just "default" the best solution and xfs detect itself whats > >best. > >> >> > >> >> 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 > >use > >> > 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 > >> 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.... > For 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.... > 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. 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. > In 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... > In 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 david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
