linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "L.A. Walsh" <xfs@tlinx.org>
To: linux-xfs@vger.kernel.org
Subject: Fwd: default mount options
Date: Tue, 29 Nov 2016 15:51:36 -0800	[thread overview]
Message-ID: <583E1488.7090502@tlinx.org> (raw)


Is it possible for the 'mount' man page to be enhanced to show
what the defaults are?  Or if that's not possible,
maybe the xfs(5) manpage?

Also, I'm again "unclear" on barriers.

The xfs(5) man page says:

 "barrier|nobarrier - Enables/disables the use of block layer write
 barriers... this allows for drive level write caching to be enabled.
 Barriers are enabled by default.

This seems to say that barriers are enabled.  Does that mean
the the barriers are implemented in the HW of the disk, or that
SW adds "barriers" for disks that don't have them implemented in HW?

It also says drives may enable write-caching -- but this should
only be done if they support write barriers.  How is this "decided"?
I.e is it done "automatically" in HW? in SW? 
Or should the user "know"?

Is this related to whether or not the drives support "state" over
power interruptions?  By having non-volatile "write-cache" memory,
battery-backed cache, or backed by a UPS?  Wouldn't SSD's be
considers safe for this purpose (because their state is non-volatile?).

I seem to "get" this topic periodically, but after some time passes,
and upon rereading the associated manpages, I realize I'm not
real clear which way is what and realize the lack of defaults
being specified and whether or not SSD's and/or UPS-backed disks
were safe whether barriers were present or not was still vague.


Thanks!
-linda









             reply	other threads:[~2016-11-29 23:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-29 23:51 L.A. Walsh [this message]
2016-11-30  0:14 ` Fwd: default mount options Eric Sandeen
2016-11-30 19:27   ` L A Walsh
2016-11-30 19:50     ` Eric Sandeen
2016-11-30 20:04       ` L A Walsh
2016-11-30 20:13         ` Eric Sandeen
2016-11-30 22:18         ` Dave Chinner
2016-12-01  4:04           ` L A Walsh
2016-12-01 10:50             ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=583E1488.7090502@tlinx.org \
    --to=xfs@tlinx.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).