On Thu, 2 Jan 2014 16:41:03 +0100, David Sterba wrote:
On Thu, Dec 26, 2013 at 02:45:10PM +0800, Qu Wenruo wrote:
Btrfs can be remounted without barrier, but there is no "barrier" option
so nobody can remount btrfs back with barrier on. Only umount and
mount again can re-enable barrier.(Quite awkward)
Ok for adding the mount option.

Reported-by: Daniel Blueman <dan...@quora.org>
Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com>
---
  Documentation/filesystems/btrfs.txt | 6 ++++++
  fs/btrfs/super.c                    | 8 +++++++-
  2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/filesystems/btrfs.txt 
b/Documentation/filesystems/btrfs.txt
index 5dd282d..f6f71d6 100644
--- a/Documentation/filesystems/btrfs.txt
+++ b/Documentation/filesystems/btrfs.txt
@@ -51,6 +51,12 @@ Unless otherwise specified, all options default to off.
        defrag process.  Works best for small files; Not well suited for
        large database workloads.
+ barrier
+       Enable the use of block layer write barriers.  Write barriers ensure
+       that certain IOs make it through the device cache and are on persistent
+       storage.
+       Barriers are enabled by default.
There's the 'nobarrier' option already, I think it's better to keep the
pairing option documentation at one place and mark the default one with (*).

Related to that, there should imho be a pairing option for every mount
option where it makes sense, so all the combinations work through
remount.

The defaults do not need to be listed via btrfs_show_options, ie. keep
the output same as it is now.


david

Thanks for pointing out these problem.

This makes sense.Like space_cache and nospace_cache follows the way you mentioned,
but most other options just followed the alphabet order, and a lot of
pairing is missing.

I'll try to add all the missingpairing and unify mount options in the document.

Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to