Robert White posted on Thu, 05 Jun 2014 20:31:21 -0700 as excerpted: > Is there a way to store the default mount options in the file system a > la ext4 and tune2fs?
Short answer, no, for most options at least. It has been discussed and will probably appear in the future, most likely in the form of expanded btrfs properties. (FWIW, there's limited property support in current btrfs-progs userspace. It doesn't cover this use-case well, yet, however.) > In particular my initrd mounts the file system and then the system > remounts it using fstab, but this tends to lead to rebuilds of the inode > cache. The initrd doesn't have the inode_cache option but the fstab > does. This creates lots "meh" on occasion. The fact that you didn't mention /why/ you've opted to use the inode_cache mount option suggests to me that you may not be aware of the fact that in general, it's not recommended for use and is generally "considered harmful" as the negatives (including this one, cache rebuilding) tend to outweigh the positives. Inode_cache can be useful in certain specific circumstances on 32-bit kernels, but is extremely unlikely to be useful on 64-bit at all, and on 32-bit, there are general complications including an overflow possibility that mean it's definitely not a general-usage recommended option there either. The special case where it /might/ be useful is busy 32-bit servers such as fileservers or mail machines with more or less constant create/delete file activity, due to the smaller inode space and possible saved time in searching for a free inode-number. Such servers tend not to be rebooted too often either, so an at-mount inode-cache rebuild isn't as big an issue as it would be on for instance a typical desktop. So unless you really can support your choice to enable that option, because you're on 32-bit and at least have a use-case where it should help, or better yet, have actually benchmarked your use-case and *KNOW* it helps, just disable inode_cache. That said and applicable to this specific case, in the more general case... > It Would Be Better™ if there were a way to store that sort of thing on > the file system itself. Said feature was very easy to use on ext4 for > dealing with xattr and such. Definitely agreed, here. As I said, it's likely to happen at some point, but it's not there now. That said, a reasonable initr* should have multiple ways to provide mount options for the rootfs. Among other possibilities, passing rootflags= on the kernel commandline should work[1] with a decent initr* as it does without an initr* at all -- a good initr* will pass them on to the mount command used to mount the rootfs. In that case, you'd configure rootflags= to be passed to the kernel from the bootloader as you would any other kernel parameter. Additionally, a good initr* builder should have some configuration option for passing additional mount-option flags, either by grabbing them from the system fstab directly, or configuration file option, or by initr* build program commandline option, if not all three. (Dracut is one such "good" initr* builder. Like many core Linux applications, it's Red Hat sponsored, but that doesn't mean it's limited to the Red Hat family of distros, and it is one recommended option for users who need an initr* solution on gentoo, my distribution, as well. But I'd be extremely surprised if any similar distro solution doesn't have at least ONE of these methods to pass rootfs mount options working, since it is after all relatively critical and basic functionality, without which many users may not be able to successfully mount their rootfs at all!) But any such solution is ideally simply an alternative to being able to configure default mount options for the filesystem itself, and IMO, btrfs continues to remain broken as a mainline filesystem successor to the ext* series, until such time as it has some such filesystem default mount options configuration option, the more so because it has so many btrfs specific options one may actually wish to pass. So I too consider btrfs currently broken in that regard, but I don't expect to see it stay that way forever. After all, it's still under very active development, with both features and bugfixes very much still appearing in every kernel release cycle, and I expect that to continue to be the case for at least another year, as it continues to mature and fully stabilize. =:^) --- [1] rootflags=: There's one known exception that affects btrfs. The btrfs device= mount option cannot be properly passed in rootflags=, apparently due to containing = as well. Apparently the kernel parser splits at the last equals and parses the option to which parameters are appended as rootflags=device, instead of a base rootflags. And since it doesn't recognize rootflags=device as rootflags, it doesn't pass the given options on as it should. Unfortunately, that breaks initr*less direct-rootfs mount, for multi-device btrfs rootfs, so they require an initr* where they otherwise would not. -- 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
