On Mon, 27 Jan 2014 23:09:55 +0100 KC <impacto...@googlemail.com> wrote:
> I forgot to ask about space_cache. Should it be off on SSD (ie > nospace_cache)? [I don't see this on the list (which I read/reply-to using nntp via gmane.org's list2news service) yet, so I'll reply to both the list and you directly via mail...] The default is now space_cache -- formerly a btrfs needed mounted with it once, after which the option was "sticky" and applied by default so it didn't need to be used again, and I believe the wiki mount-option documentation at least still says that, but for at least several kernels, the option seems to be on by default -- I never mounted with space_cache specifically given here, yet all my btrfs have it listed in /proc/self/mounts. So space-cache is now the default unless specifically turned off. And while I don't have a specific reason to use it on ssd, I don't have a good reason not to either, so not knowing anything specific I figured I'd be best sticking with the defaults. So on my btrfs on SSDs, space_cache is default-on simply because it's the default and I know no good reason to mess with the defaults in that case. Actually I hadn't even thought of it in the context of something else to record and thus to contribute to write-cycles, if there's no real benefit to it on SSDs otherwise, but I guess there is, or it'd default to off when ssds are detected, just like the ssd option is automatically turned on in that case. (In general, btrfs should in most cases be able to detect ssd if it's on the "bare metal" physical device or a partition on it. If the btrfs is on top of lvm or mdraid, however, or on some other mid-layer virtual device, it's less likely to properly detect ssd, and you'd likely need to turn that option on manually.) -- Duncan - No HTML messages please, as they are filtered as spam. "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
