2

I'm running Arch Linux with BTRFS. This computer has 3 physical HDD's (and no RAID, etc.). I have a disk mounted at /, one at /cow and one at /nocow. Here is the fstab:

# /etc/fstab
# <file system> <dir>   <type>  <options>       <dump>  <pass>
UUID=a101       /               btrfs           rw,noatime,nodiratime,compress=lzo,space_cache,subvol=/@ 0 0
UUID=b202       /cow            btrfs           rw,noatime,nodiratime,compress=lzo,space_cache,subvol=/@cow 0 0
UUID=c303       /nocow          btrfs           rw,noatime,nodiratime,compress=lzo,space_cache,nodatacow,subvol=/@nocow 0 0

I understand that nodatacow is a filesystem mount option and, therefore, it will apply to all mounted subvolumes of that filesystem, when used. But I don't have a clear definition of a filesystem. At times, a filesystem can span multiple disks. Is that what is happening with the fstab above? Does mounting one disk with nodatacow make that option apply to all three of my physical disks? Or, because when I formatted each disk separately and a BTRFS filesystem was created on each disk, do I have 3 separate filesystems?

On a related topic, I understand that when nodatacow is enabled, compression is disabled. I assume that means I should remove compress=lzo from the options for mounting my 3rd disk, like this:

UUID=c303 /nocow btrfs rw,noatime,nodiratime,space_cache,nodatacow,subvol=/@nocow 0 0

The most important question is whether mounting this 3rd disk with the nodatacow option affects the entire filesystem (all 3 disks and all directories under /) or just the (portion of) the filesystem under the mount point /nocow.

Would it be better to use chattr +C /nocow? I did not do that because I am not sure if that attribute affects a filesystem that is later mounted at that directory (and mounted without the nodatacow option).

/nocow holds some mysql databases.

1 Answer 1

3

I understand that nodatacow is a filesystem mount option and, therefore, it will apply to all mounted subvolumes of that filesystem, when used. But I don't have a clear definition of a filesystem. At times, a filesystem can span multiple disks. Is that what is happening with the fstab above?

Since you are mounting three different UUIDs I suspect that you indeed have three separate filesystems.

However, you are also specifying subvolumes in your mounts. This shows me that you probably have the following layout:

HDD1
└──── Filesystem 1 (a101)
      └──── Subvolume /@ mounted at /
HDD2
└──── Filesystem 2 (b202)
      └──── Subvolume /@cow mounted at /cow
HDD3
└──── Filesystem 3 (c303)
      └──── Subvolume /@nocow mounted at /nocow

You have three separate filesystems, each with one subvolume. In this case the nodatacow mount option can be applied to each of the three filesystems separately.

With btrfs however, you could also have only one filesystem (possibly spanning multiple HDDs and possibly but not necessarily using some form of RAID) and mount separate subvolumes (similar to folders) of that one filesystem to separate places. This would mean you would have some layout like this:

HDD1 [...HDDn]
└──── Filesystem 1
      ├──── Subvolume /@ mounted at /
      ├──── Subvolume /@cow mounted at /cow
      └──── Subvolume /@nocow mounted at /nocow

In that case a nodatacow mount option would apply to all subvolumes since they reside on the same filesystem.

Does mounting one disk with nodatacow make that option apply to all three of my physical disks?

No.

Or, because when I formatted each disk separately and a BTRFS filesystem was created on each disk, do I have 3 separate filesystems?

Yes.

On a related topic, I understand that when nodatacow is enabled, compression is disabled.

That is true [1] and you can remove that mount option on the /nocow mount. But since you have three separate filesystems the other two (/ and /cow) can still be mounted with compression enabled if you like.

Would it be better to use chattr +C /nocow?

Using extended file attributes like this to achieve nocow operation is a possible alternative but:

  • You have to chattr +C folders if they are still empty!
  • You either have to create new files only in folders that are already chattr +C or first touch them and then copy the contents into them (details at [2]).

Thus, it might be easier to use the nodatacow mount option and a separate filesystem for VM or DB files similar to what you already did. (You could think about whether to use Btrfs at all for that filesystem since it does not have many benefits in this use case.)

Generally when storing VM or DB files on btrfs consider to also include the autodefrag mount option since otherwise big VM or DB files with many random writes may quickly fragment and deteriorate performance [3].

[1] https://btrfs.wiki.kernel.org/index.php/Compression#How_does_compression_interact_with_direct_IO_or_COW.3F

[2] https://btrfs.wiki.kernel.org/index.php/FAQ#Can_copy-on-write_be_turned_off_for_data_blocks.3F

[3] https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation

You must log in to answer this question.

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