default mount options 3.10

Hi,
can someone tell me which mount options are included in "defaults" mount option? Couldn't find this in BTRFS Wiki. I'm using Debian Wheezy 7.1 and Linux kernel 3.10.6. Thanks in advance.

Best Regards
David

Hi,
you've looked at the wrong place.

FILESYSTEM INDEPENDENT MOUNT OPTIONS
defaults : Use default options: rw, suid, dev, exec, auto, nouser, async

You can also have a look here [1].

Best regards,
Xavier

[1] https://wiki.debian.org/fstab#Field_definitions

Am Freitag, 23. August 2013, 12:29:42 schrieb Xavier Bassery:

That are just VFS options, no BTRFS specific ones.

A good way is to look at output of "mount" and "cat /proc/mounts". It can differ from situation as well, for example SSD or not.

But some hints at BTRFS default options are also on (search for "default"):

https://btrfs.wiki.kernel.org/index.php/Mount_options

I don´t know wether there is a complete documentation on the defaults.

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Martin Steigerwald posted on Fri, 23 Aug 2013 14:58:07 +0200 as excerpted:

FWIW, space_cache seems to be the default now, and for ssds (detected if sysfs has a device rotation value of zero), ssd. There's some others that are the normal default now, but aren't listed (flushoncommit is one), as running with those features disabled can increase performance but also dramatically increases chance of data loss, so it's not recommended.

Compression options are the big ones you may want to add, but they aren't default as usage is too varied for them to be a sane default. And of course ssd if it applies and isn't detected, and possibly ssd_spread.

I recommend autodefrag for general use, as well, but you'll want to have it enabled when you first start copying data to the filesystem, and some distros don't enable it by default and setup a system on btrfs, which means there's fragmentation to begin with, and performance will probably be bad for awhile (even on newly setup systems!) when the option is first enabled as a result. You can readup on defrag on the wiki for a defrag command that should fix the problem, but unfortunately the command isn't as straightforward as one might expect. (Also note that if compression is enabled, a compressed file over a certain size, 128 MiB IIRC, but I'm not sure if that's compressed or uncompressed size, will appear fragmented to filefrag no matter what. That's an artifact of the way btrfs handles compression.)

Inode_cache LOOKS good, but beware; people have reported problems with it and unsafe shutdowns or the like. So it's probably best to avoid it unless you really need it for your workload and judge it to be worth the risk. That's why it's not the default, yet.

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

At least Fedora's installer developers have made it pretty clear they don't intend to use non-default mount options like this. So if autodefrag is really that important for general use, it needs to be part of the default mount options. And quite honestly, with as many changes that happen with btrfs, I think it's better if btrfs developers are making the decisions to add/remove what they think should be current default mount options for general purpose, rather than installer developers or users. Especially when the command isn't straightforward.

Chris Murphy

Duncan posted on Sat, 24 Aug 2013 12:23:18 +0000 as excerpted:

[mount-option discussion]

One that I omitted in my previous discussion because it's not btrfs specific, but that makes a rather larger difference than normal on btrfs, especially with lots of snapshots, is noatime. Unfortunately, for legacy reasons, that can't be the default, but unless you're running mutt (which needs atime to track read messages except with mbox) or something similar, there really are very few even half-modern apps that require atime, and it really is best to run with noatime, saving the constant access-time update writes.

The general kernel default is now relatime, which is a compromise that works reasonably well on most filesystems, but even that tends to trigger way more atime updates and thus de-dupped metadata when dealing with btrfs snapshots than would be optimal.

Similarly, limited-write-cycle SSDs will do best with noatime. If you happen to be running btrfs on ssd as I am, well...

So just run with noatime unless you are running something (like mutt) that is known to need atimes, and then, preferably limit it to a particular dedicated filesystem, perhaps choosing a filesystem other than btrfs or at least a limited-snapshot btrfs.

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