From: Andrew Price <anprice@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] gfs2(5): add rgrplbv and loccookie info the the manpage
Date: Mon, 9 May 2016 16:10:19 +0100 [thread overview]
Message-ID: <5730A85B.6000101@redhat.com> (raw)
In-Reply-To: <20160415222214.GD2988@octiron.msp.redhat.com>
On 15/04/16 23:22, Benjamin Marzinski wrote:
> The only issue with these patches is that they are geared for upstream.
> Instead of listing the 3.6 and 4.5 linux kernels, the RHEL man pages
> should list the relevant rhel kernels. I suppose the easiest way to
> deal with this would be to patch them in the rhel rpms.
That sounds like the way to go. Looks good to me.
Thanks,
Andy
>
> -Ben
>
> On Fri, Apr 15, 2016 at 11:33:43AM -0500, Benjamin Marzinski wrote:
>> The gfs2 man page didn't have any information about the rgrplvb and
>> loccookie mount options. This patch adds it.
>>
>> Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
>> ---
>> gfs2/man/gfs2.5 | 34 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/gfs2/man/gfs2.5 b/gfs2/man/gfs2.5
>> index 0517944..56d1a00 100644
>> --- a/gfs2/man/gfs2.5
>> +++ b/gfs2/man/gfs2.5
>> @@ -165,6 +165,40 @@ the statfs information on a local basis before it is synced back
>> to the master statfs file, even if the time period has not
>> expired. If the setting of statfs_quantum is 0, then this setting
>> is ignored.
>> +.TP
>> +\fBrgrplvb\fP
>> +This flag tells gfs2 to look for information about a resource group's free
>> +space and unlinked inodes in its glock lock value block. This keeps gfs2 from
>> +having to read in the resource group data from disk, speeding up allocations in
>> +some cases. This option was added in the 3.6 Linux kernel. Prior to this
>> +kernel, no information was saved to the resource group lvb. \fBNote:\fP To
>> +safely turn on this option, all nodes mounting the filesystem must be running
>> +at least a 3.6 Linux kernel. If any nodes had previously mounted the filesystem
>> +using older kernels, the filesystem must be unmounted on all nodes before it
>> +can be mounted with this option enabled. This option does not need to be
>> +enabled on all nodes using a filesystem.
>> +.TP
>> +\fBloccookie\fP
>> +This flag tells gfs2 to use location based readdir cookies, instead of its
>> +usual filename hash readdir cookies. The filename hash cookies are not
>> +guaranteed to be unique, and as the number of files in a directory increases,
>> +so does the likelihood of a collision. NFS requires readdir cookies to be
>> +unique, which can cause problems with very large directories (over 100,000
>> +files). With this flag set, gfs2 will try to give out location based cookies.
>> +Since the cookie is 31 bits, gfs2 will eventually run out of unique cookies,
>> +and will fail back to using hash cookies. The maximum number of files that
>> +could have unique location cookies assuming perfectly even hashing and names of
>> +8 or fewer characters is 1,073,741,824. An average directory should be able to
>> +give out well over half a billion location based cookies. This option was added
>> +in the 4.5 Linux kernel. Prior to this kernel, gfs2 did not add directory
>> +entries in a way that allowed it to use location based readdir cookies.
>> +\fBNote:\fP To safely turn on this option, all nodes mounting the filesystem
>> +must be running at least a 4.5 Linux kernel. If this option is only enabled on
>> +some of the nodes mounting a filesystem, the cookies returned by nodes using
>> +this option will not be valid on nodes that are not using this option, and vice
>> +versa. Finally, when first enabling this option on a filesystem that had been
>> +previously mounted without it, you must make sure that there are no outstanding
>> +cookies being cached by other software, such as NFS.
>>
>> .SH BUGS
>>
>> --
>> 2.1.0
>
prev parent reply other threads:[~2016-05-09 15:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-15 16:33 [Cluster-devel] [PATCH] gfs2(5): add rgrplbv and loccookie info the the manpage Benjamin Marzinski
2016-04-15 22:22 ` Benjamin Marzinski
2016-05-09 15:10 ` Andrew Price [this message]
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=5730A85B.6000101@redhat.com \
--to=anprice@redhat.com \
/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).