From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs check --repair is clean, but mount fails
Date: Sun, 28 Feb 2016 06:49:21 +0000 (UTC) [thread overview]
Message-ID: <pan$5fdff$39b005f1$778b3960$a3d0b01e@cox.net> (raw)
In-Reply-To: 20160228030930.GS19699@merlins.org
Marc MERLIN posted on Sat, 27 Feb 2016 19:09:30 -0800 as excerpted:
[line in fstab]
> LABEL=btrfs_space /var/local/space btrfs subvol=varlocalspace,defaults,compress=lzo,skip_balance,noatime,noexec 0 0
Nothing to do with your issue at hand, but some potentially useful info, FWIW...
The "defaults" mount option in fstab is just that, the defaults, and
doesn't really apply as an option because they /are/ the defaults. The
only reason for "defaults" as an explicit option to exist is to hold the
options field in the case of no non-default option being there to hold it,
so once there's _any_ non-default option added, "defaults" can be removed,
as the non-default option is now holding the field and the defaults apply
anyway unless overruled by some other option.
Additionally, with any reasonably modern util-linux, the last two fields,
dump and fsck-passno, both default to 0 if not present, so don't need to
be explicitly included if zero, unless of course you want to as a matter of
style, possibly for consistency with other fstab entries where the fields are
needed, perhaps because fsck-passno isn't zero and you need the dump field
of zero as a field-holder to have the non-zero fsck-passno in the correct
field.
Of course neither the two trailing zero fields nor the defaults mount
option do any harm, and you may simply be including them as a matter of
style. But because the options field in particular can be rather long, as
yours certainly is, knowing that you can skip "defaults" as a mount option
can be quite a useful hint, if you weren't aware of it before.
So FWIW, YMMV, etc, but I thought it might be worth mentioning, for other
readers for whom it might be new and useful info, even if it's "the way
you like it, ****it!" for you. =:^)
FWIW the fstab (5) manpage is the official documentation for it, but it
says effectively what I said above. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2016-02-28 6:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-27 2:39 btrfs check --repair is clean, but mount fails Marc MERLIN
2016-02-27 2:45 ` Liu Bo
2016-02-27 3:03 ` Marc MERLIN
2016-02-27 18:06 ` Liu Bo
2016-02-28 1:04 ` Marc MERLIN
2016-02-27 22:58 ` Anand Jain
2016-02-28 0:56 ` Marc MERLIN
2016-02-28 1:44 ` Anand Jain
2016-02-28 3:09 ` Marc MERLIN
2016-02-28 6:49 ` Duncan [this message]
2016-02-28 13:56 ` Marc MERLIN
2016-02-28 5:17 ` Marc MERLIN
2016-02-28 6:11 ` Anand Jain
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='pan$5fdff$39b005f1$778b3960$a3d0b01e@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@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).