Bug 829042 - [FEAT] selective read-only mode
[FEAT] selective read-only mode
Status: CLOSED DUPLICATE of bug 1265574
Product: GlusterFS
Classification: Community
Component: unclassified (Show other bugs)
Unspecified Unspecified
low Severity unspecified
: ---
: ---
Assigned To: Saravanakumar
: FutureFeature, Reopened
Depends On:
Blocks: 1302203 1265574
  Show dependency treegraph
Reported: 2012-06-05 16:24 EDT by Csaba Henk
Modified: 2016-01-27 02:02 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1265574 (view as bug list)
Last Closed: 2015-10-23 02:24:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Csaba Henk 2012-06-05 16:24:02 EDT
Description of problem:

Read-only has already been integrated to the volume set framework so we can enforce read-only operation to a given volume (ie. all mounts of it will be read-only). However, we need to fine-tune this feature so that read-only / writable behavior shall be chosen according to the context of the client access, ie. whether it's normal or internal maintenance mount, and within latter, the type of maintenance access (eg. geo-replication, rebalance, etc.).

The feature should be general -- so, if say glusterfs knows of N contexts, which are (according to the current convention) represented as -1, -2, ..., -N values for client-pid (and non-negative client-pids mean normal access, ie. it corresponds to the actual pid the request came from [0 for kernel]), (the union of) any set of the {|x| x >= 0}, -1, -2,..., -N value ranges should be possible to specify as the ones where read-only access is enforced.
Comment 2 Kaleb KEITHLEY 2015-10-22 11:46:38 EDT
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.
Comment 3 Saravanakumar 2015-10-23 01:58:19 EDT
moving back to NEW, as this is a required feature.
Comment 4 Vivek Agarwal 2015-10-23 02:24:09 EDT

*** This bug has been marked as a duplicate of bug 1265574 ***

Note You need to log in before you can comment on or make changes to this bug.