| Alexey Dobriyan | 335debe | 2009-01-22 10:27:30 +0300 | [diff] [blame] | 1 | config BTRFS_FS |
| 2 | tristate "Btrfs filesystem (EXPERIMENTAL) Unstable disk format" |
| 3 | depends on EXPERIMENTAL |
| 4 | select LIBCRC32C |
| 5 | select ZLIB_INFLATE |
| 6 | select ZLIB_DEFLATE |
| Li Zefan | a6fa6fa | 2010-10-25 15:12:26 +0800 | [diff] [blame] | 7 | select LZO_COMPRESS |
| 8 | select LZO_DECOMPRESS |
| David Woodhouse | 53b381b | 2013-01-29 18:40:14 -0500 | [diff] [blame^] | 9 | select RAID6_PQ |
| 10 | |
| Alexey Dobriyan | 335debe | 2009-01-22 10:27:30 +0300 | [diff] [blame] | 11 | help |
| 12 | Btrfs is a new filesystem with extents, writable snapshotting, |
| 13 | support for multiple devices and many more features. |
| 14 | |
| 15 | Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET |
| 16 | FINALIZED. You should say N here unless you are interested in |
| 17 | testing Btrfs with non-critical data. |
| 18 | |
| 19 | To compile this file system support as a module, choose M here. The |
| 20 | module will be called btrfs. |
| 21 | |
| 22 | If unsure, say N. |
| Christian Hesse | bef62ef | 2009-02-04 09:28:28 -0500 | [diff] [blame] | 23 | |
| 24 | config BTRFS_FS_POSIX_ACL |
| 25 | bool "Btrfs POSIX Access Control Lists" |
| 26 | depends on BTRFS_FS |
| 27 | select FS_POSIX_ACL |
| 28 | help |
| 29 | POSIX Access Control Lists (ACLs) support permissions for users and |
| 30 | groups beyond the owner/group/world scheme. |
| 31 | |
| 32 | To learn more about Access Control Lists, visit the POSIX ACLs for |
| 33 | Linux website <http://acl.bestbits.at/>. |
| 34 | |
| 35 | If you don't know what Access Control Lists are, say N |
| Stefan Behrens | c975dd4 | 2011-11-01 17:06:04 +0100 | [diff] [blame] | 36 | |
| 37 | config BTRFS_FS_CHECK_INTEGRITY |
| 38 | bool "Btrfs with integrity check tool compiled in (DANGEROUS)" |
| 39 | depends on BTRFS_FS |
| 40 | help |
| 41 | Adds code that examines all block write requests (including |
| 42 | writes of the super block). The goal is to verify that the |
| 43 | state of the filesystem on disk is always consistent, i.e., |
| 44 | after a power-loss or kernel panic event the filesystem is |
| 45 | in a consistent state. |
| 46 | |
| 47 | If the integrity check tool is included and activated in |
| 48 | the mount options, plenty of kernel memory is used, and |
| 49 | plenty of additional CPU cycles are spent. Enabling this |
| 50 | functionality is not intended for normal use. |
| 51 | |
| 52 | In most cases, unless you are a btrfs developer who needs |
| 53 | to verify the integrity of (super)-block write requests |
| 54 | during the run of a regression test, say N |