Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: setting per-mount options via .meta #1785

Closed
csabahenk opened this issue Nov 12, 2020 · 3 comments
Closed

RFE: setting per-mount options via .meta #1785

csabahenk opened this issue Nov 12, 2020 · 3 comments
Assignees
Labels
assigned This bug has at least one 'assignee'. It will not get 'stale' label. Type:Enhancement wontfix Managed by stale[bot]

Comments

@csabahenk
Copy link
Member

Problem

Options that affect a single mount can only be set as command line options (--opt1 VAL1 --opt2 VAL2... style options for glusterfs, or -oopt1=VAL1,opt2=VAL2... style options for mount.glusterfs), and they are in effect for the whole lifetime of the mount. Such options includes ones that have both volume-level and mount-level variants (eg. diagnostics.client-log-level volume option ~ --log-level command line option) and most importantly, options for the fuse translator.

This latter case is important because it sets apart the fuse xlator UI-wise: while options of other translators are possible to adjust at runtime via cli, fuse translator options can only be affected at mount time, via command line options. This is justified technically, as fuse is the fixed root of the xlator graph which is re-grafted upon a graph switch (that happens upon adjusting volume options at runtime), but weird from user's perspective; and not only weird, but thoroughly unpractical as several fuse options have a heavy impact on glusterfs behavior, and it's cumbersome that a remount is needed to adjust them (becoming an obstacle to getting diagnostical data and experimenting with flexible performance tuning).

Solution

The .meta tree

Glusterfs has a less known reflection facility, the .meta hidden (= readdir doesn't list it) subtree. Under this entry various live statistics are available. At this moment it's a read-only tree.

Plan

Export per mount (or at least fuse xlator) options in writable manner under .meta, similarly to how procfs / sysfs exposes various kernel tunables.

While the xlator option space will still remain divided — fuse options are per-mount and .meta tunable, other xlator options are per-volume and cli tunable —, which is probably not completely reasonable from user POV, it makes sense to have a split UI-wise between per-mount (.meta tunable) and per-volume (cli tunable) options. That is, if a user doesn't bother about how options are dispatched to particular xlators, then the UI split will make sense to her according to scope of the setting.

@amarts
Copy link
Member

amarts commented Nov 13, 2020

@csabahenk this is critical enhancement.

This was one reason I was trying to have 'global' translator for every volume. More on this @ #303

I feel a global xlator is better because it can be controlled with cli in that case (for all clients). I would still like a meta overload because it helps in debugging in one particular mount point.

@amarts amarts added the assigned This bug has at least one 'assignee'. It will not get 'stale' label. label May 28, 2021
csabahenk added a commit to csabahenk/glusterfs that referenced this issue Oct 20, 2021
The .meta synthetic tree features the options entry
for each xlator, which lets us see the options with
which the translator was configured. Technically,
'options' exports the options dict with which the
given xlator has been configured. This approach
provides read-only access to the xlator options,
and only those options are visible which has been
set.

We implement an alternative options entry (referred
to as 'aadjustable options' in the sequel) that
exports the full option set of the xlator. We
extended the volume_options stucture wih 'fetch'
and 'update' methods, that facilitate access to
the realtime values of the xlator options. In
the adjustable options dict each option is readable
which has 'fetch' and if they have 'update' too,
then they shall be writable (this is properly
reflected in file modes since 2554080).

While the dict-based options is generic and provides
an export mechanism for xlator options without specific
support from the xlators, adjustable options will export
only those options for which the xlator implements
fetch/update.

We made this effort for the fuse xlator, which is positioned
in glusterfs client as the root of the xlator tree, and thus
can't be 'hot-swapped' like other xlators via graph switch.

All the fuse options obained 'fetch'; and the ones where
runtime update is possible also 'update' (ie. those which
control the internal behavior of the filesystem server, can
be updated; the ones which are mount options or init options
for the FUSE infrastucture, can't).

**
THIS IS A WIP implementation, misses one thing: adjustability
of fuse dumping, which will need more specific support code due
to the involvement of external resource
**

Change-Id: I72cb0f3c2f93712cd08147a4ae2e076354d8d9d8
Fixes: gluster#1785
Signed-off-by: Csaba Henk <csaba@redhat.com>
csabahenk added a commit to csabahenk/glusterfs that referenced this issue Nov 15, 2021
The .meta synthetic tree features the options entry
for each xlator, which lets us see the options with
which the translator was configured. Technically,
'options' exports the options dict with which the
given xlator has been configured. This approach
provides read-only access to the xlator options,
and only those options are visible which has been
set.

We implement an alternative options entry (referred
to as 'aadjustable options' in the sequel) that
exports the full option set of the xlator. We
extended the volume_options stucture wih 'fetch'
and 'update' methods, that facilitate access to
the realtime values of the xlator options. In
the adjustable options dict each option is readable
which has 'fetch' and if they have 'update' too,
then they shall be writable (this is properly
reflected in file modes since 2554080).

While the dict-based options is generic and provides
an export mechanism for xlator options without specific
support from the xlators, adjustable options will export
only those options for which the xlator implements
fetch/update.

We made this effort for the fuse xlator, which is positioned
in glusterfs client as the root of the xlator tree, and thus
can't be 'hot-swapped' like other xlators via graph switch.

All the fuse options obained 'fetch'; and the ones where
runtime update is possible also 'update' (ie. those which
control the internal behavior of the filesystem server, can
be updated; the ones which are mount options or init options
for the FUSE infrastucture, can't).

Change-Id: I72cb0f3c2f93712cd08147a4ae2e076354d8d9d8
Fixes: gluster#1785
Signed-off-by: Csaba Henk <csaba@redhat.com>
csabahenk added a commit to csabahenk/glusterfs that referenced this issue Nov 27, 2021
The .meta synthetic tree features the options entry
for each xlator, which lets us see the options with
which the translator was configured. Technically,
'options' exports the options dict with which the
given xlator has been configured. This approach
provides read-only access to the xlator options,
and only those options are visible which has been
set.

We implement an alternative options entry (referred
to as 'aadjustable options' in the sequel) that
exports the full option set of the xlator. We
extended the volume_options stucture wih 'fetch'
and 'update' methods, that facilitate access to
the realtime values of the xlator options. In
the adjustable options dict each option is readable
which has 'fetch' and if they have 'update' too,
then they shall be writable (this is properly
reflected in file modes since 2554080).

While the dict-based options is generic and provides
an export mechanism for xlator options without specific
support from the xlators, adjustable options will export
only those options for which the xlator implements
fetch/update.

We made this effort for the fuse xlator, which is positioned
in glusterfs client as the root of the xlator tree, and thus
can't be 'hot-swapped' like other xlators via graph switch.

All the fuse options obained 'fetch'; and the ones where
runtime update is possible also 'update' (ie. those which
control the internal behavior of the filesystem server, can
be updated; the ones which are mount options or init options
for the FUSE infrastucture, can't).

Change-Id: I72cb0f3c2f93712cd08147a4ae2e076354d8d9d8
Fixes: gluster#1785
Signed-off-by: Csaba Henk <csaba@redhat.com>
csabahenk added a commit to csabahenk/glusterfs that referenced this issue Nov 30, 2021
The .meta synthetic tree features the options entry
for each xlator, which lets us see the options with
which the translator was configured. Technically,
'options' exports the options dict with which the
given xlator has been configured. This approach
provides read-only access to the xlator options,
and only those options are visible which has been
set.

We implement an alternative options entry (referred
to as 'adjustable options' in the sequel) that
exports the full option set of the xlator. We
extended the volume_options stucture wih 'fetch'
and 'update' methods, that facilitate access to
the realtime values of the xlator options. In
the adjustable options dict each option is readable
which has 'fetch' and if they have 'update' too,
then they shall be writable (this is properly
reflected in file modes since 2554080).

While the dict-based options is generic and provides
an export mechanism for xlator options without specific
support from the xlators, adjustable options will export
only those options for which the xlator implements
fetch/update.

We made this effort for the fuse xlator, which is positioned
in glusterfs client as the root of the xlator tree, and thus
can't be 'hot-swapped' like other xlators via graph switch.

All the fuse options obained 'fetch'; and the ones where
runtime update is possible also 'update' (ie. those which
control the internal behavior of the filesystem server, can
be updated; the ones which are mount options or init options
for the FUSE infrastucture, can't).

Change-Id: I72cb0f3c2f93712cd08147a4ae2e076354d8d9d8
Fixes: gluster#1785
Signed-off-by: Csaba Henk <csaba@redhat.com>
csabahenk added a commit to csabahenk/glusterfs that referenced this issue Nov 30, 2021
The .meta synthetic tree features the options entry
for each xlator, which lets us see the options with
which the translator was configured. Technically,
'options' exports the options dict with which the
given xlator has been configured. This approach
provides read-only access to the xlator options,
and only those options are visible which has been
set.

We implement an alternative options entry (referred
to as 'adjustable options' in the sequel) that
exports the full option set of the xlator. We
extended the volume_options stucture wih 'fetch'
and 'update' methods, that facilitate access to
the realtime values of the xlator options. In
the adjustable options dict each option is readable
which has 'fetch' and if they have 'update' too,
then they shall be writable (this is properly
reflected in file modes since 2554080).

While the dict-based options is generic and provides
an export mechanism for xlator options without specific
support from the xlators, adjustable options will export
only those options for which the xlator implements
fetch/update.

We made this effort for the fuse xlator, which is positioned
in glusterfs client as the root of the xlator tree, and thus
can't be 'hot-swapped' like other xlators via graph switch.

All the fuse options obained 'fetch'; and the ones where
runtime update is possible also 'update' (ie. those which
control the internal behavior of the filesystem server, can
be updated; the ones which are mount options or init options
for the FUSE infrastucture, can't).

Change-Id: I72cb0f3c2f93712cd08147a4ae2e076354d8d9d8
Fixes: gluster#1785
Signed-off-by: Csaba Henk <csaba@redhat.com>
@stale
Copy link

stale bot commented Dec 26, 2021

Thank you for your contributions.
Noticed that this issue is not having any activity in last ~6 months! We are marking this issue as stale because it has not had recent activity.
It will be closed in 2 weeks if no one responds with a comment here.

@stale stale bot added the wontfix Managed by stale[bot] label Dec 26, 2021
@stale
Copy link

stale bot commented Jan 15, 2022

Closing this issue as there was no update since my last update on issue. If this is an issue which is still valid, feel free to open it.

@stale stale bot closed this as completed Jan 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assigned This bug has at least one 'assignee'. It will not get 'stale' label. Type:Enhancement wontfix Managed by stale[bot]
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants