Chris Murphy posted on Fri, 04 Mar 2016 19:46:34 -0700 as excerpted: > On Fri, Mar 4, 2016 at 4:16 PM, Martin Mlynář <ne...@smoula.net> wrote:
[Mount options line split/wrapped for followup] >>>> rw,noatime,nodatasum,nodatacow,ssd,discard,space_cache, >>>> enospc_debug,commit=900,subvolid=5,subvol=/ >>> >>> Most likely unrelated but commit time of 15 minutes? Umm, OK why? >> >> I'm trying to reduce writes to my ssd. > > This will not reduce writes. It will only delay them. And it increases > the chance of data loss by a lot. AFAIK, to the extent that temporary files are created and then deleted again, within that 900 seconds aka 15 minutes, it will indeed reduce writes. This can be the case for the build-tmp location for people running build- from-sources distros such as gentoo, for instance, as many packages will be built and tmp-installed to that build-tmp, before being quick-merged to the live system and the work deleted from build-tmp in well under 15 minutes, at least on today's reasonably powerful quad-core-plus systems. Tho on gentoo, the recommendation for those with the memory available is to point that build-tmp at a tmpfs instead of a permanent-storage backed filesystem of any sort. And in general, for those without the memory to support build-tmp in tmpfs, a 15-minute commit time isn't going to help either, because if they have enough memory to avoid flushing to free up memory for that full 15 minutes, they obviously have enough memory to store all those files that would be in tmpfs if they'd have simply pointed build-tmp at that, instead. Another use-case is laptops and other mobile systems with enough memory to cache the normal working set, is to power down the storage devices for as long as possible between powerups. However, the heavy power usage there is normally on spinning up the disk and/or keeping it spinning, and SSDs obviously aren't subject to that. While some small amount of power may still be saved by powering down the SSD, I expect it to be pretty small, and the writes are going to take the same amount of power no matter when they're done. In either case, 15 minute commit times are rather extreme, because as has been pointed out, that's potentially 15 minutes of lost work should the system crash before those writes are completed, and losing 15 minutes worth of work is well beyond the acceptable risk level for most people. 5 minutes, much more common, 10 minutes, not so common but you'll fine people doing it. 15 minutes, pretty rare, I expect. The point being, yes, there are use-cases where 15 minute commit times makes sense. But the given reason, a bare wish to reduce writes to the ssd, without support such as one of the above use-cases or something similar, really doesn't make sense, at least on its face. I'll agree with other posters on that. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
