5

After I read a bit about Btrfs I figured out it has many features I would like to use in the future, like snapshots, compression, defrag, enhancemence for SSD drives and so on. So I decided to acutally give that a try.

I converted my Ext4 home directory to Btrfs like this:

btrfs-convert /dev/mapper/system-home

Now the next tasks would be to create a propper entry for the /etc/fstab which currently still looks like this.

/dev/mapper/system-home /home ext4 nosuid,noexec,usrquota,grpquota 0 2

I am not quite sure about the noexec and the nosuid option. Does Btrfs understand these options? What would be the correct mount options for the Btrfs filesystem?

3 Answers 3

5

The direct answer to your question is:

/dev/mapper/system-home /home btrfs defaults 0 2

  • "btrfs" instead of ext4
  • "defaults" says to use the default options. Many people don't know that you don't have to specify mount options for every file system.

My personal preference for btrfs is this:

/dev/mapper/system-home /home btrfs noatime,nodiratime,compress=lzo 0 2

which are:

  • noatime (no access time): don't keep a time stamp every time a file is read; only time stamp when a file is changed. (Most people don't even know that there is a file access time stamp, and most people don't need it, so don't waste resources writing to the disk when you are only reading something.)
  • nodiratime (no directory access time): same thing for directories.
  • compress=lzo : compress files using the lzo compression method. LZO is fast, and the compression is invisible, so this is a big win for text files.
7
  • yeah thanks man. i did know about the noatime option but as you said i think i do not really need it. i simply checked and at least noexec also works with btrfs. the lzo compression i will test.
    – l1zard
    Commented Apr 7, 2015 at 20:48
  • 3
    The last integer of the fstab entry should be a 0 because Btrfs does not do a file system check on boot.
    – jaltek
    Commented Mar 21, 2016 at 15:38
  • In my experience, because Btrfs does not do a file system check on boot, it doesn't matter what the last integer is in the fstab entry. It can be a 0, or a 2, or anything-- it is ignored at boot time from what I've seen.
    – Grunthos
    Commented Mar 23, 2016 at 23:12
  • 3
    I've read several places that noatime implies nodiratime; is there a need to specify both? Personal preference, but I get it appears "not to matter", but putting in 2 just because still seems weird. The wiki says to use zero and that fsck.btrfs will get called if pass is non-zero. That said, it looks to not do anything and just refer you to look into btrfs check.
    – Hendy
    Commented Feb 10, 2017 at 14:40
  • I think you've found clarifications of details that weren't as well-known when this question was answered two years ago. Good work; thanks for sharing! On noatime vs nodiratime, it is still unclear to me if that is the same for all filesystem types, or if it varies. I find direct statements about it for ext3/4 and xfs, but I haven't seen btrfs docs address it directly. There is no harm, at least, in specifying both. :-)
    – Grunthos
    Commented Feb 11, 2017 at 17:13
1

I am not quite sure about the noexec and the nosuid option.

If you mean you're not sure what these options mean they are both security or system protection measures-

  1. nosuid prevents a program (executable) that is loaded from that mount/ filesystem from running with "set User ID" privileges. Setuid programs are typically utilities that need to run with high (maybe root) privileges, even if they are started by ordinary users.
  2. noexec prevents the execution of any programs from that mount point (and therefore it renders the nosuid redundant).

Letting users upload or write their own programs from their own home directories obviously involves some risk to the system. Letting users run setuid programs involves much more risk. Using both options is a belt+braces approach to avoiding that risk.

1

In the mount manpage, both exec/noexec and suid/nosuid are listed under the sections Filesystem-independent mount options. This means that they are implemented at or above the VFS layer in the kernel, and don't require any support from the filesystem.

The short answer is that both noexec and nosuid will continue to work exactly the same as they did for your ext4 filesystem.

You might want to also consider adding nodev to the options.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .