aboutsummaryrefslogtreecommitdiffstats
path: root/block/Kconfig
blob: 7cdaa1d722528372591377c60e3695e3ec9d0b16 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
#
# Block layer core configuration
#
menuconfig BLOCK
       bool "Enable the block layer" if EMBEDDED
       default y
       help
	 Provide block layer support for the kernel.

	 Disable this option to remove the block layer support from the
	 kernel. This may be useful for embedded devices.

	 If this option is disabled:

	   - block device files will become unusable
	   - some filesystems (such as ext3) will become unavailable.

	 Also, SCSI character devices and USB storage will be disabled since
	 they make use of various block layer definitions and facilities.

	 Say Y here unless you know you really don't want to mount disks and
	 suchlike.

if BLOCK

config LBD
	bool "Support for large block devices and files"
	depends on !64BIT
	help
	  Enable block devices or files of size 2TB and larger.

	  This option is required to support the full capacity of large
	  (2TB+) block devices, including RAID, disk, Network Block Device,
	  Logical Volume Manager (LVM) and loopback.
	
	  This option also enables support for single files larger than
	  2TB.

	  The ext4 filesystem requires that this feature be enabled in
	  order to support filesystems that have the huge_file feature
	  enabled.    Otherwise, it will refuse to mount any filesystems
	  that use the huge_file feature, which is enabled by default
	  by mke2fs.ext4.   The GFS2 filesystem also requires this feature.

	  If unsure, say N.

config BLK_DEV_IO_TRACE
	bool "Support for tracing block io actions"
	depends on SYSFS
	select RELAY
	select DEBUG_FS
	select TRACEPOINTS
	select TRACING
	select STACKTRACE
	help
	  Say Y here if you want to be able to trace the block layer actions
	  on a given queue. Tracing allows you to see any traffic happening
	  on a block device queue. For more information (and the userspace
	  support tools needed), fetch the blktrace tools from:

	  git://git.kernel.dk/blktrace.git

	  Tracing also is possible using the ftrace interface, e.g.:

	    echo 1 > /sys/block/sda/sda1/trace/enable
	    echo blk > /sys/kernel/debug/tracing/current_tracer
	    cat /sys/kernel/debug/tracing/trace_pipe

	  If unsure, say N.

config BLK_DEV_BSG
	bool "Block layer SG support v4 (EXPERIMENTAL)"
	depends on EXPERIMENTAL
	---help---
	  Saying Y here will enable generic SG (SCSI generic) v4 support
	  for any block device.

	  Unlike SG v3 (aka block/scsi_ioctl.c drivers/scsi/sg.c), SG v4
	  can handle complicated SCSI commands: tagged variable length cdbs
	  with bidirectional data transfers and generic request/response
	  protocols (e.g. Task Management Functions and SMP in Serial
	  Attached SCSI).

	  If unsure, say N.

config BLK_DEV_INTEGRITY
	bool "Block layer data integrity support"
	---help---
	Some storage devices allow extra information to be
	stored/retrieved to help protect the data.  The block layer
	data integrity option provides hooks which can be used by
	filesystems to ensure better data integrity.

	Say yes here if you have a storage device that provides the
	T10/SCSI Data Integrity Field or the T13/ATA External Path
	Protection.  If in doubt, say N.

endif # BLOCK

config BLOCK_COMPAT
	bool
	depends on BLOCK && COMPAT
	default y

source block/Kconfig.iosched