Those are different sets of words both describing the same scenario; I don't see anything inconsistent, although they were written by different authors years apart; they simply approach it from different angles.

However,

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-writebarriers.html

explains the situation quite thoroughly, if you find the short blurbs in the manpage to be confusing.

Hi,
how I did, and a chance is other novice man pages readers will too, understand man page was to - use barriers to disable barriers.
While redhat web docs say - nobarrier - man for mount xfs does not even mention it. Also nothing about discard.
I think - should man page get an update (6.5) ?

Well, the manpage does not say "use barriers to disable barriers" - I'm not sure where you got that idea.

You're right that the mount(8) manpage does not mention "nobarrier" for xfs, and it probably should.

There is a desire to move fs-specific mount options into fs-specific mount manpages, so at some point we may make that change, and keep all of the xfs options directly under xfs developer control.

If you have a high priority need for this change, please contact your Red Hat support representative to open a case and prioritize this work, and they can re-open this bug when and attach it to your support case.

Thanks,
-Eric

(the mount(8) manpage is part of the util-linux package, not xfsprogs, FWIW)

but am I right about misleading and incorrect wording on "barrier"?
Man pages says use "barrier" to disable barrier whereas it should have been "nobarrier" which man page says nothing of.

(In reply to lejeczek from comment #6)

> Man pages says use "barrier" to disable barrier

The manpage says:

       barrier
              Enables the use of block layer write barriers  for  writes  into
              the  journal  and  unwritten extent conversion.  This allows for
              drive level write caching to be enabled, for devices  that  sup-
              port write barriers.

I don't see any mention of disabling anything...

It says that if you use barriers, you can enable drive write caches safely.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/xfsmounting.html

all I'm saying is that man pages fox xfs it would be nice, well, required that both options barrier & nobarrier are explained and even compared, so we would not have to guess nor assume. (nor sroogle) (also discard, maybe others, just on par with what the code offers us, you know)

yeah, fair enough.  We should at least have all xfs mount options documented.

Karel, what do you think about a mount(8) update to be sure it's in sync w/ the fs/* code we ship?

The current upstream man page:

 barrier | nobarrier
 Enables/disables the use of block layer write barriers for
 writes into the journal and for data integrity operations.
 This allows for drive level write caching to be enabled, for
 devices that support write barriers.

The upstream goal is to keep it in sync with kernel Documentation/filesystems/xfs.txt, I'd like to avoid mount.8 specific descriptions.

No problem to backport it to RHEL6 -- but if there is a difference between the current kernel and RHEL6 then we need someone from XFS camp to provide RHEL6 compatible descriptions.

Karel, fair enough, I'll provide text that's appropriate for RHEL6.

And some day - really - make a manpage we can ship from xfsprogs...

FWIW, we do have mount options in xfs.5 now ;)

commit 53ab4c490be46b0df0eb4f3626c083d6c5e715be
Author: Eric Sandeen <sandeen>
Date:   Thu Jun 19 12:14:01 2014 +1000

    xfsprogs: add mount options to xfs.5 manpage
    
    This is a straight cut and paste from the util-linux
    mount manpage to xfs.5.
    
    It's pretty much impossible for util-linux to keep up
    with every filesystem out there, and Karel has more than
    once expressed a wish that mount options move into fs-specific
    manpages.
    
    So, here we go.
    
    Signed-off-by: Eric Sandeen <sandeen>
    Reviewed-by: Dave Chinner <dchinner>
    Signed-off-by: Dave Chinner <david>


-Eric

(In reply to Eric Sandeen from comment #14)
> FWIW, we do have mount options in xfs.5 now ;)

Cool, thanks!

I guess you don't plan to backport the man page to RHEL{6,7}, right?

Well, we could.  Do we need to coordinate that with mount(8) changes for consistency?

If you decide to backport the man page, then it would be probably nice to erase XFS stuff from mount.8 (I did that in upstream tree for f23).

Not sure if this makes sense for RHEL6, maybe we can do the change for RHEL7 only -- I guess add two BZ (xfsprogs and util-linux) with mutual dependence should be enough.

AFAIK it's already done for rhel7, at least from the xfsprogs & e2fsprogs POV...

xfsprogs was done in v3.2.1, and we're shipping 3.2.2 now.
e2fsprogs was done in v1.42.11, and we're shipping 1.42.9, but the mount options were included when bug #1053885 was fixed.

For RHEL6, I have synced mount.8 with the latest version from upstream where we had XFS mount options. For RHEL >= 7 and Fedora we have xfs man page.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0911.html