[Gluster-Maintainers] [Gluster-devel] Please pause merging patches to 3.9 waiting for just one patch
Manikandan Selvaganesh
manikandancs333 at gmail.com
Fri Nov 11 10:02:26 UTC 2016
Thanks Sanoj for the work and pasting the work in detail.
--
Thanks & Regards,
Manikandan Selvaganesan.
(@Manikandan Selvaganesh on Web)
On Fri, Nov 11, 2016 at 3:31 PM, Manikandan Selvaganesh <
manikandancs333 at gmail.com> wrote:
> Yes Sanoj, that's the issue. It will somehow write the latest header which
> has conf 1.2.
> But for all the individual gfid's it won't work properly always. We need
> to do it many times
> and sometimes it will be still not set properly.
>
> --
> Thanks & Regards,
> Manikandan Selvaganesan.
> (@Manikandan Selvaganesh on Web)
>
> On Fri, Nov 11, 2016 at 12:47 PM, Sanoj Unnikrishnan <sunnikri at redhat.com>
> wrote:
>
>> Pasting Testing Logs
>> ======================
>>
>> 3.6
>>
>> [root at dhcp-0-112 rpms]# /sbin/gluster v create v1 $tm1:/export/sdb/br1
>> volume create: v1: success: please start the volume to access data
>>
>> [root at dhcp-0-112 rpms]# gluster v start v1
>> [root at dhcp-0-112 rpms]#
>> [root at dhcp-0-112 rpms]# mount -t glusterfs $tm1:v1 /gluster_vols/vol
>> [root at dhcp-0-112 rpms]# gluster v quota v1 enable
>> volume quota : success
>> [root at dhcp-0-112 rpms]#
>> [root at dhcp-0-112 rpms]# mkdir -p /gluster_vols/vol/dir1; gluster v
>> quota v1 limit-usage /dir1 5MB 10
>> volume quota : success
>> [root at dhcp-0-112 rpms]# mkdir -p /gluster_vols/vol/dir2; gluster v
>> quota v1 limit-usage /dir2 16MB 10
>> volume quota : success
>> [root at dhcp-0-112 rpms]# gluster v quota v1 list
>> Path Hard-limit Soft-limit Used
>> Available Soft-limit exceeded? Hard-limit exceeded?
>> ------------------------------------------------------------
>> ---------------------------------------------------------------
>> /dir1 5.0MB 10% 0Bytes
>> 5.0MB No No
>> /dir2 16.0MB 10% 0Bytes
>> 16.0MB No No
>> [root at dhcp-0-112 rpms]#
>> [root at dhcp-0-112 rpms]#
>> [root at dhcp-0-112 rpms]# rpm -qa | grep glusterfs-ser
>> glusterfs-server-3.6.9-0.1.gitcaccd6c.fc24.x86_64
>>
>> [root at dhcp-0-112 rpms]# umount /gluster_vols/vol
>> [root at dhcp-0-112 rpms]#
>>
>> [root at dhcp-0-112 rpms]# cat /var/lib/glusterd/vols/v1/quota.conf
>> [root at dhcp-0-112 rpms]# hexdump /var/lib/glusterd/vols/v1/quota.conf
>>
>> [root at dhcp-0-112 rpms]# hexdump -c /var/lib/glusterd/vols/v1/quota.conf
>> 0000000 G l u s t e r F S Q u o t a
>> 0000010 c o n f | v e r s i o n :
>> 0000020 v 1 . 1 \n U \t 213 I 252 251 C 337 262 x \b
>> 0000030 i y r 5 021 312 335 w 366 X 5 B H 210 260 227
>> 0000040 ^ 251 X 237 G
>> 0000045
>> [root at dhcp-0-112 rpms]#
>>
>> [root at dhcp-0-112 rpms]# getfattr -d -m. -e hex /export/sdb/br1/dir1/ |
>> grep gfid
>> getfattr: Removing leading '/' from absolute path names
>> trusted.gfid=0x55098b49aaa943dfb278086979723511
>> [root at dhcp-0-112 rpms]# getfattr -d -m. -e hex /export/sdb/br1/dir2/ |
>> grep gfid
>> getfattr: Removing leading '/' from absolute path names
>> trusted.gfid=0xcadd77f65835424888b0975ea9589f47
>>
>> [root at dhcp-0-112 rpms]# gluster v stop v1
>> Stopping volume will make its data inaccessible. Do you want to continue?
>> (y/n) y
>> volume stop: v1: success
>>
>> [root at dhcp-0-112 rpms]# pkill glusterd
>>
>> +++++++++++++++++++ Replace with 3.9 build without patch++++++++++
>>
>> [root at dhcp-0-112 3.9]# systemctl start glusterd
>> [root at dhcp-0-112 3.9]#
>> [root at dhcp-0-112 3.9]# rpm -qa | grep glusterfs-ser
>> glusterfs-server-3.9.0rc2-0.13.gita3bade0.fc24.x86_64
>> [
>> [root at dhcp-0-112 3.9]# gluster v set all cluster.op-version 30700
>> volume set: success
>>
>> [root at dhcp-0-112 3.9]# gluster v start v1
>> volume start: v1: success
>>
>> [root at dhcp-0-112 3.9]# mount -t glusterfs $tm1:v1 /gluster_vols/vol
>>
>> >> not sure why we see this , second attempt succeeds
>> [root at dhcp-0-112 3.9]# gluster v quota v1 limit-usage /dir1 12MB 10
>> quota command failed : Failed to start aux mount
>> [root at dhcp-0-112 3.9]#
>> [root at dhcp-0-112 3.9]# gluster v quota v1 limit-usage /dir2 12MB 10
>> volume quota : success
>>
>> [root at dhcp-0-112 3.9]# hexdump -c /var/lib/glusterd/vols/v1/quota.conf
>> 0000000 G l u s t e r F S Q u o t a
>> 0000010 c o n f | v e r s i o n :
>> 0000020 v 1 . 2 \n U \t 213 I 252 251 C 337 262 x \b
>> 0000030 i y r 5 021 001 312 335 w 366 X 5 B H 210 260
>> 0000040 227 ^ 251 X 237 G 001
>> 0000047
>> [root at dhcp-0-112 3.9]# gluster v quota v1 list
>> Path Hard-limit Soft-limit
>> Used Available Soft-limit exceeded? Hard-limit exceeded?
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>> /dir1 5.0MB 10%(512.0KB)
>> 0Bytes 5.0MB No No
>> /dir2 12.0MB 10%(1.2MB)
>> 0Bytes 12.0MB No No
>> [root at dhcp-0-112 3.9]#
>> [root at dhcp-0-112 3.9]# gluster v quota v1 limit-usage /dir1 12MB 10
>>
>> [root at dhcp-0-112 3.9]# cksum /var/lib/glusterd/vols/v1/quota.conf
>> 496616948 71 /var/lib/glusterd/vols/v1/quota.conf
>> [root at dhcp-0-112 3.9]#
>>
>> >> Now we disable , followed by enable and set the same limits to check
>> if we get the same quota.conf contents
>>
>> [root at dhcp-0-112 3.9]# /sbin/gluster v quota v1 disable
>> Disabling quota will delete all the quota configuration. Do you want to
>> continue? (y/n) y
>> quota command failed : Volume quota failed. The cluster is operating at
>> version 30700. Quota command disable is unavailable in this version.
>> [root at dhcp-0-112 3.9]#
>>
>> >> we need to upgrade to 3_7_12 to use disable
>>
>> [root at dhcp-0-112 3.9]# gluster v set all cluster.op-version 30712
>> volume set: success
>> [root at dhcp-0-112 3.9]# /sbin/gluster v quota v1 disable
>> Disabling quota will delete all the quota configuration. Do you want to
>> continue? (y/n) y
>> volume quota : success
>>
>> [root at dhcp-0-112 3.9]# /sbin/gluster v quota v1 enable
>> volume quota : success
>>
>> >> again we hit it,
>>
>> [root at dhcp-0-112 3.9]# gluster v quota v1 limit-usage /dir1 12MB 10
>> quota command failed : Failed to start aux mount
>> [root at dhcp-0-112 3.9]#
>> [root at dhcp-0-112 3.9]# gluster v quota v1 limit-usage /dir1 12MB 10
>> volume quota : success
>> [root at dhcp-0-112 3.9]# gluster v quota v1 limit-usage /dir2 12MB 10
>> volume quota : success
>>
>> >> we get same quota.conf contents, confirming that the limit-usage
>> rewrites quota.conf correctly
>> [root at dhcp-0-112 3.9]# cksum /var/lib/glusterd/vols/v1/quota.conf
>> 496616948 71 /var/lib/glusterd/vols/v1/quota.conf
>>
>>
>> I Notice that while the limit-usage command does rewrite quota.conf
>> correctly, the command does not always succeed.
>> So the user may have to try it multiple times.
>>
>>
>> Thanks and Regards,
>> Sanoj
>>
>>
>>
>>
>>
>> On Fri, Nov 11, 2016 at 2:42 AM, Vijay Bellur <vbellur at redhat.com> wrote:
>>
>>> On Thu, Nov 10, 2016 at 11:56 AM, Niels de Vos <ndevos at redhat.com>
>>> wrote:
>>> > On Thu, Nov 10, 2016 at 11:44:21AM -0500, Vijay Bellur wrote:
>>> >> On Thu, Nov 10, 2016 at 11:14 AM, Shyam <srangana at redhat.com> wrote:
>>> >> > On 11/10/2016 11:01 AM, Vijay Bellur wrote:
>>> >> >>
>>> >> >> On Thu, Nov 10, 2016 at 10:49 AM, Shyam <srangana at redhat.com>
>>> wrote:
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> On 11/10/2016 10:21 AM, Vijay Bellur wrote:
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
>>> >> >>>> <manikandancs333 at gmail.com> wrote:
>>> >> >>>> Given that we are done with the last release in 3.6.x, I think
>>> there
>>> >> >>>> would be users looking to upgrade. My vote is to include the
>>> >> >>>> necessary patches in 3.9 and not let users go through unnatural
>>> >> >>>> workflows to get quota working again in 3.9.0.
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> <Comment is without knowing if the necessary patches are good to
>>> go>
>>> >> >>>
>>> >> >>> Consider this a curiosity question ATM,
>>> >> >>>
>>> >> >>> 3.9 is an LTM, right? So we are not stating workflows here are
>>> set in
>>> >> >>> stone?
>>> >> >>> Can this not be an projected workflow?
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >> 3.9 is a STM release as per [1].
>>> >> >
>>> >> >
>>> >> > Sorry, I meant STM.
>>> >> >
>>> >> >>
>>> >> >> Irrespective of a release being LTM or not, being able to upgrade
>>> to a
>>> >> >> release without operational disruptions is a requirement.
>>> >> >
>>> >> >
>>> >> > I would say upgrade to an STM *maybe* painful, as it is an STM and
>>> hence may
>>> >> > contain changes that are yet to be announced stable or changed
>>> workflows
>>> >> > that are not easy to upgrade to. We do need to document them
>>> though, even
>>> >> > for the STM.
>>> >> >
>>> >> > Along these lines, the next LTM should be as stated, i.e "without
>>> >> > operational disruptions". The STM is for adventurous folks, no?
>>> >> >
>>> >>
>>> >> In my view STM releases for getting new features out early. This would
>>> >> enable early adopters to try and provide feedback about new features.
>>> >> Existing features and upgrades should work smoothly. IOW, we do not
>>> >> want to have known regressions for existing features in STM releases.
>>> >> New features might have rough edges and this should be amply
>>> >> advertised.
>>> >
>>> > I do not think users on 3.6 are the right consumers for a STM release.
>>> > These users are conservative and did not ugrade earlier. I doubt they
>>> > are interested in new features *now*. Users that did not upgrade
>>> before,
>>> > are unlikely the users that will upgrade in three months when 3.9 is
>>> > EOL.
>>> >
>>> >> In this specific case, quota has not undergone any significant changes
>>> >> in 3.9 and letting such a relatively unchanged feature affect users
>>> >> upgrading from 3.6 does not seem right to me. Also note that since
>>> >> LATEST in d.g.o would point to 3.9.0 after the release, users
>>> >> performing package upgrades on their systems could end up with 3.9.0
>>> >> inadvertently.
>>> >
>>> > The packages from the CentOS Storage SIG will by default provide the
>>> > latest LTM release. The STM release is provided in addition, and needs
>>> > an extra step to enable.
>>> >
>>> > I am not sure how we can handle this in other distributions (or also
>>> > with the packages on d.g.o.).
>>>
>>> Maybe we should not flip the LATEST for non-RPM distributions in
>>> d.g.o? or should we introduce LTM/LATEST and encourage users to change
>>> their repository files to point to this?
>>>
>>> Packaging in distributions would be handled by package maintainers and
>>> I presume they can decide the appropriateness of a release for
>>> packaging?
>>>
>>> Thanks,
>>> Vijay
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> Gluster-devel at gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20161111/7585e964/attachment-0001.html>
More information about the maintainers
mailing list