(shred invocation): Clarify that shred

works on ext3 as long as it's not in data=journal mode.
Patch from Mark Melahn.

1 files changed, 11 insertions, 2 deletions

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index c2e39afd2..b85d2b3eb 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7349,8 +7349,8 @@ assumption.  Exceptions include:
 
 @item
 Log-structured or journaled file systems, such as those supplied with
-AIX and Solaris, and JFS, ReiserFS, XFS, Ext3, BFS, NTFS etc.@: when
-they are configured to journal @emph{data}.
+AIX and Solaris, and JFS, ReiserFS, XFS, Ext3 (in @code{data=journal} mode),
+BFS, NTFS, etc.@: when they are configured to journal @emph{data}.
 
 @item
 File systems that write redundant data and carry on even if some writes
@@ -7367,6 +7367,15 @@ clients.
 Compressed file systems.
 @end itemize
 
+In the particular case of ext3 filesystems, the above disclaimer applies (and
+@command{shred} is thus of limited effectiveness) only in @code{data=journal}
+mode, which journals file data in addition to just metadata. In both
+the @code{data=ordered} (default) and @code{data=writeback} modes,
+@command{shred} works as usual.  Ext3 journaling modes can be changed
+by adding the @code{data=something} option to the mount options for a
+particular file system in the @file{/etc/fstab} file, as documented in
+the mount man page (man mount).
+
 If you are not sure how your file system operates, then you should assume
 that it does not overwrite data in place, which means that shred cannot
 reliably operate on regular files in your file system.