[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:01:37 UTC 2016
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/7bfc9fe4/attachment-0001.html>
More information about the maintainers
mailing list