__generic_block_fiemap(): fix for files bigger than 4GB
[safe/jmp/linux-2.6] / fs / ext3 / Kconfig
index fb3c1a2..522b154 100644 (file)
@@ -29,23 +29,25 @@ config EXT3_FS
          module will be called ext3.
 
 config EXT3_DEFAULTS_TO_ORDERED
-       bool "Default to 'data=ordered' in ext3 (legacy option)"
+       bool "Default to 'data=ordered' in ext3"
        depends on EXT3_FS
        help
-         If a filesystem does not explicitly specify a data ordering
-         mode, and the journal capability allowed it, ext3 used to
-         historically default to 'data=ordered'.
-
-         That was a rather unfortunate choice, because it leads to all
-         kinds of latency problems, and the 'data=writeback' mode is more
-         appropriate these days.
-
-         You should probably always answer 'n' here, and if you really
-         want to use 'data=ordered' mode, set it in the filesystem itself
-         with 'tune2fs -o journal_data_ordered'.
-
-         But if you really want to enable the legacy default, you can do
-         so by answering 'y' to this question.
+         The journal mode options for ext3 have different tradeoffs
+         between when data is guaranteed to be on disk and
+         performance.  The use of "data=writeback" can cause
+         unwritten data to appear in files after an system crash or
+         power failure, which can be a security issue.  However,
+         "data=ordered" mode can also result in major performance
+         problems, including seconds-long delays before an fsync()
+         call returns.  For details, see:
+
+         http://ext4.wiki.kernel.org/index.php/Ext3_data_mode_tradeoffs
+
+         If you have been historically happy with ext3's performance,
+         data=ordered mode will be a safe choice and you should
+         answer 'y' here.  If you understand the reliability and data
+         privacy issues of data=writeback and are willing to make
+         that trade off, answer 'n'.
 
 config EXT3_FS_XATTR
        bool "Ext3 extended attributes"