[Gluster-devel] glusterfsd crash due to page allocation failure

2015-12-21 Thread Glomski, Patrick 
Hello,

We've recently upgraded from gluster 3.6.6 to 3.7.6 and have started
encountering dmesg page allocation errors (stack trace is appended).

It appears that glusterfsd now sometimes fills up the cache completely and
crashes with a page allocation failure. I *believe* it mainly happens when
copying lots of new data to the system, running a 'find', or similar. Hosts
are all Scientific Linux 6.6 and these errors occur consistently on two
separate gluster pools.

Has anyone else seen this issue and are there any known fixes for it via
sysctl kernel parameters or other means?

Please let me know of any other diagnostic information that would help.

Thanks,
Patrick


[1458118.134697] glusterfsd: page allocation failure. order:5, mode:0x20
> [1458118.134701] Pid: 6010, comm: glusterfsd Not tainted
> 2.6.32-573.3.1.el6.x86_64 #1
> [1458118.134702] Call Trace:
> [1458118.134714]  [] ? __alloc_pages_nodemask+0x7dc/0x950
> [1458118.134728]  [] ? mlx4_ib_post_send+0x680/0x1f90
> [mlx4_ib]
> [1458118.134733]  [] ? kmem_getpages+0x62/0x170
> [1458118.134735]  [] ? fallback_alloc+0x1ba/0x270
> [1458118.134736]  [] ? cache_grow+0x2cf/0x320
> [1458118.134738]  [] ? cache_alloc_node+0x99/0x160
> [1458118.134743]  [] ? pskb_expand_head+0x62/0x280
> [1458118.134744]  [] ? __kmalloc+0x199/0x230
> [1458118.134746]  [] ? pskb_expand_head+0x62/0x280
> [1458118.134748]  [] ? __pskb_pull_tail+0x2aa/0x360
> [1458118.134751]  [] ? harmonize_features+0x29/0x70
> [1458118.134753]  [] ? dev_hard_start_xmit+0x1c4/0x490
> [1458118.134758]  [] ? sch_direct_xmit+0x15a/0x1c0
> [1458118.134759]  [] ? dev_queue_xmit+0x228/0x320
> [1458118.134762]  [] ? neigh_connected_output+0xbd/0x100
> [1458118.134766]  [] ? ip_finish_output+0x287/0x360
> [1458118.134767]  [] ? ip_output+0xb8/0xc0
> [1458118.134769]  [] ? __ip_local_out+0x9f/0xb0
> [1458118.134770]  [] ? ip_local_out+0x25/0x30
> [1458118.134772]  [] ? ip_queue_xmit+0x190/0x420
> [1458118.134773]  [] ? __alloc_pages_nodemask+0x129/0x950
> [1458118.134776]  [] ? tcp_transmit_skb+0x4b4/0x8b0
> [1458118.134778]  [] ? tcp_write_xmit+0x1da/0xa90
> [1458118.134779]  [] ? __kmalloc_node+0x4d/0x60
> [1458118.134780]  [] ? tcp_push_one+0x30/0x40
> [1458118.134782]  [] ? tcp_sendmsg+0x9cc/0xa20
> [1458118.134786]  [] ? sock_aio_write+0x19b/0x1c0
> [1458118.134788]  [] ? sock_aio_write+0x0/0x1c0
> [1458118.134791]  [] ? do_sync_readv_writev+0xfb/0x140
> [1458118.134797]  [] ? autoremove_wake_function+0x0/0x40
> [1458118.134801]  [] ? selinux_file_permission+0xbf/0x150
> [1458118.134804]  [] ? security_file_permission+0x16/0x20
> [1458118.134806]  [] ? do_readv_writev+0xd6/0x1f0
> [1458118.134807]  [] ? vfs_writev+0x46/0x60
> [1458118.134809]  [] ? sys_writev+0x51/0xd0
> [1458118.134812]  [] ? __audit_syscall_exit+0x25e/0x290
> [1458118.134816]  [] ? system_call_fastpath+0x16/0x1b
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Call for volunteer for 3.7.7 release-manager

2015-12-21 Thread Vijay Bellur 

On 11/24/2015 04:31 AM, Raghavendra Talur wrote:

Hi,

3.7.7 is scheduled to be released by end of this month.
The release tracker for the same is
https://bugzilla.redhat.com/show_bug.cgi?id=1279240


We are in need of a release-manager for the same; please reply in thread
if you wish to volunteer.



Pranith has volunteered to be the release manager for 3.7.7. Thank you, 
Pranith!


-Vijay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] volume-snapshot.t failures

2015-12-21 Thread Raghavendra Gowdappa 
Seems like a snapshot failure on build machines. Found another failure:
https://build.gluster.org/job/rackspace-regression-2GB-triggered/17066/console

Test failed:
./tests/basic/tier/tier-snapshot.t

Debug-msg:
++ gluster --mode=script --wignore snapshot create snap2 patchy no-timestamp
snapshot create: failed: Pre-validation failed on localhost. Please check log 
file for details
+ test_footer
+ RET=1
+ local err=
+ '[' 1 -eq 0 ']'
+ echo 'not ok 11 '
not ok 11 
+ '[' x0 = x0 ']'
+ echo 'FAILED COMMAND: gluster --mode=script --wignore snapshot create snap2 
patchy no-timestamp'
FAILED COMMAND: gluster --mode=script --wignore snapshot create snap2 patchy 
no-timestamp

- Original Message -
> From: "Raghavendra Gowdappa" 
> To: "Rajesh Joseph" 
> Sent: Tuesday, December 22, 2015 10:05:22 AM
> Subject: volume-snapshot.t failures
> 
> Hi Rajesh
> 
> There is a failure of volume-snapshot.t on build machine:
> https://build.gluster.org/job/rackspace-regression-2GB-triggered/17048/consoleFull
> 
> 
> However, on my local machine test succeeds always. Is it a known case of
> spurious failure?
> 
> regards,
> Raghavendra.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] glusterfsd crash due to page allocation failure

2015-12-21 Thread Pranith Kumar Karampuri 

hi Glomski,
This is the second time I am hearing about memory allocation 
problems in 3.7.6 but this time on brick side. Are you able to recreate 
this issue? Will it be possible to get statedumps of the bricks 
processes just before they crash?


Pranith

On 12/22/2015 02:25 AM, Glomski, Patrick wrote:

Hello,

We've recently upgraded from gluster 3.6.6 to 3.7.6 and have started 
encountering dmesg page allocation errors (stack trace is appended).


It appears that glusterfsd now sometimes fills up the cache completely 
and crashes with a page allocation failure. I *believe* it mainly 
happens when copying lots of new data to the system, running a 'find', 
or similar. Hosts are all Scientific Linux 6.6 and these errors occur 
consistently on two separate gluster pools.


Has anyone else seen this issue and are there any known fixes for it 
via sysctl kernel parameters or other means?


Please let me know of any other diagnostic information that would help.

Thanks,
Patrick


[1458118.134697] glusterfsd: page allocation failure. order:5,
mode:0x20
[1458118.134701] Pid: 6010, comm: glusterfsd Not tainted
2.6.32-573.3.1.el6.x86_64 #1
[1458118.134702] Call Trace:
[1458118.134714]  [] ?
__alloc_pages_nodemask+0x7dc/0x950
[1458118.134728]  [] ?
mlx4_ib_post_send+0x680/0x1f90 [mlx4_ib]
[1458118.134733]  [] ? kmem_getpages+0x62/0x170
[1458118.134735]  [] ? fallback_alloc+0x1ba/0x270
[1458118.134736]  [] ? cache_grow+0x2cf/0x320
[1458118.134738]  [] ?
cache_alloc_node+0x99/0x160
[1458118.134743]  [] ? pskb_expand_head+0x62/0x280
[1458118.134744]  [] ? __kmalloc+0x199/0x230
[1458118.134746]  [] ? pskb_expand_head+0x62/0x280
[1458118.134748]  [] ? __pskb_pull_tail+0x2aa/0x360
[1458118.134751]  [] ? harmonize_features+0x29/0x70
[1458118.134753]  [] ?
dev_hard_start_xmit+0x1c4/0x490
[1458118.134758]  [] ? sch_direct_xmit+0x15a/0x1c0
[1458118.134759]  [] ? dev_queue_xmit+0x228/0x320
[1458118.134762]  [] ?
neigh_connected_output+0xbd/0x100
[1458118.134766]  [] ? ip_finish_output+0x287/0x360
[1458118.134767]  [] ? ip_output+0xb8/0xc0
[1458118.134769]  [] ? __ip_local_out+0x9f/0xb0
[1458118.134770]  [] ? ip_local_out+0x25/0x30
[1458118.134772]  [] ? ip_queue_xmit+0x190/0x420
[1458118.134773]  [] ?
__alloc_pages_nodemask+0x129/0x950
[1458118.134776]  [] ? tcp_transmit_skb+0x4b4/0x8b0
[1458118.134778]  [] ? tcp_write_xmit+0x1da/0xa90
[1458118.134779]  [] ? __kmalloc_node+0x4d/0x60
[1458118.134780]  [] ? tcp_push_one+0x30/0x40
[1458118.134782]  [] ? tcp_sendmsg+0x9cc/0xa20
[1458118.134786]  [] ? sock_aio_write+0x19b/0x1c0
[1458118.134788]  [] ? sock_aio_write+0x0/0x1c0
[1458118.134791]  [] ?
do_sync_readv_writev+0xfb/0x140
[1458118.134797]  [] ?
autoremove_wake_function+0x0/0x40
[1458118.134801]  [] ?
selinux_file_permission+0xbf/0x150
[1458118.134804]  [] ?
security_file_permission+0x16/0x20
[1458118.134806]  [] ? do_readv_writev+0xd6/0x1f0
[1458118.134807]  [] ? vfs_writev+0x46/0x60
[1458118.134809]  [] ? sys_writev+0x51/0xd0
[1458118.134812]  [] ?
__audit_syscall_exit+0x25e/0x290
[1458118.134816]  [] ?
system_call_fastpath+0x16/0x1b




___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] volume-snapshot.t failures

2015-12-21 Thread Raghavendra Gowdappa 
Both these tests succeed on my local machine.

- Original Message -
> From: "Raghavendra Gowdappa" 
> To: "Rajesh Joseph" 
> Cc: "Gluster Devel" 
> Sent: Tuesday, December 22, 2015 12:05:24 PM
> Subject: Re: [Gluster-devel] volume-snapshot.t failures
> 
> Seems like a snapshot failure on build machines. Found another failure:
> https://build.gluster.org/job/rackspace-regression-2GB-triggered/17066/console
> 
> Test failed:
> ./tests/basic/tier/tier-snapshot.t
> 
> Debug-msg:
> ++ gluster --mode=script --wignore snapshot create snap2 patchy no-timestamp
> snapshot create: failed: Pre-validation failed on localhost. Please check log
> file for details
> + test_footer
> + RET=1
> + local err=
> + '[' 1 -eq 0 ']'
> + echo 'not ok 11 '
> not ok 11
> + '[' x0 = x0 ']'
> + echo 'FAILED COMMAND: gluster --mode=script --wignore snapshot create snap2
> patchy no-timestamp'
> FAILED COMMAND: gluster --mode=script --wignore snapshot create snap2 patchy
> no-timestamp
> 
> - Original Message -
> > From: "Raghavendra Gowdappa" 
> > To: "Rajesh Joseph" 
> > Sent: Tuesday, December 22, 2015 10:05:22 AM
> > Subject: volume-snapshot.t failures
> > 
> > Hi Rajesh
> > 
> > There is a failure of volume-snapshot.t on build machine:
> > https://build.gluster.org/job/rackspace-regression-2GB-triggered/17048/consoleFull
> > 
> > 
> > However, on my local machine test succeeds always. Is it a known case of
> > spurious failure?
> > 
> > regards,
> > Raghavendra.
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] volume-snapshot.t failures

2015-12-21 Thread Dan Lambright 
They fail on RHEL6 machines due to an issue with sqlite. The test has been 
moved to the ignore list already (13056).
I'd like to look into having tests that do not run on RHEL6, only RHEL7+. 
I've been running it on RHEL7 the last few hours in a loop successfully.

- Original Message -
> From: "Raghavendra Gowdappa" 
> To: "Rajesh Joseph" 
> Cc: "Gluster Devel" 
> Sent: Tuesday, December 22, 2015 1:42:13 AM
> Subject: Re: [Gluster-devel] volume-snapshot.t failures
> 
> Both these tests succeed on my local machine.
> 
> - Original Message -
> > From: "Raghavendra Gowdappa" 
> > To: "Rajesh Joseph" 
> > Cc: "Gluster Devel" 
> > Sent: Tuesday, December 22, 2015 12:05:24 PM
> > Subject: Re: [Gluster-devel] volume-snapshot.t failures
> > 
> > Seems like a snapshot failure on build machines. Found another failure:
> > https://build.gluster.org/job/rackspace-regression-2GB-triggered/17066/console
> > 
> > Test failed:
> > ./tests/basic/tier/tier-snapshot.t
> > 
> > Debug-msg:
> > ++ gluster --mode=script --wignore snapshot create snap2 patchy
> > no-timestamp
> > snapshot create: failed: Pre-validation failed on localhost. Please check
> > log
> > file for details
> > + test_footer
> > + RET=1
> > + local err=
> > + '[' 1 -eq 0 ']'
> > + echo 'not ok 11 '
> > not ok 11
> > + '[' x0 = x0 ']'
> > + echo 'FAILED COMMAND: gluster --mode=script --wignore snapshot create
> > snap2
> > patchy no-timestamp'
> > FAILED COMMAND: gluster --mode=script --wignore snapshot create snap2
> > patchy
> > no-timestamp
> > 
> > - Original Message -
> > > From: "Raghavendra Gowdappa" 
> > > To: "Rajesh Joseph" 
> > > Sent: Tuesday, December 22, 2015 10:05:22 AM
> > > Subject: volume-snapshot.t failures
> > > 
> > > Hi Rajesh
> > > 
> > > There is a failure of volume-snapshot.t on build machine:
> > > https://build.gluster.org/job/rackspace-regression-2GB-triggered/17048/consoleFull
> > > 
> > > 
> > > However, on my local machine test succeeds always. Is it a known case of
> > > spurious failure?
> > > 
> > > regards,
> > > Raghavendra.
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> > 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Gluster testing matrix

2015-12-21 Thread Raghavendra Talur 
On Sat, Dec 19, 2015 at 11:28 PM, Benjamin Turner 
wrote:

> WRT performance.  I would be happy to kick of daily performance regression
> runs on what ever you guys would like.  My current daily runs don't take
> any more than 6-8 hours, I could fit another 4 hours in there for
> upstream.  I could also run them on RDMA to help out on some coverage
> there.  LMK what you think, I already have this implemented and its just a
> matter of setting how often we want it run and on what config / builds.
> LMK what you think and we can have something real quick.
>
> -b
>


Thanks for the support Ben! With your help performance category will be
mostly taken care of.
Also, Prasanna(cc'ed) here was interested to show our performance numbers
on Gluster website with charts like these[1] that he had prepared for a
perf patch of his.
You could work with him on that while we set up other test related infra.

[1]
http://nongnu.13855.n7.nabble.com/Replacing-loopback-with-Unix-Domain-Sockets-for-I-O-tp205505p205879.html




>
> On Thu, Dec 17, 2015 at 6:03 AM, Deepak Shetty 
> wrote:
>
>> Where / How do you indicate whether the underlying GlusterFS is
>> used/tested using fusemount or libgfapi method or both ?
>>
>> On Wed, Nov 25, 2015 at 5:39 PM, Raghavendra Talur 
>> wrote:
>>
>>> Hi All,
>>>
>>> Here is a table representing the current state of Gluster testing.
>>>
>>> * Things in green are categories for which we have some kind of testing
>>> in place.
>>> * Things in red are the ones which don't have any tests.
>>> * Things in yellow are the ones which have no known tests or are not
>>> managed by Gluster community.
>>>
>>>
>>>
>>> Test Category/Sub-Category
>>>
>>>
>>>
>>>
>>>
>>> smoke source build + Posix complaince + Dbench
>>>
>>>
>>>
>>>
>>> functional tests/basic
>>>
>>>
>>>
>>>
>>> regression tests/bugs
>>>
>>>
>>>
>>>
>>> performance regression N/A
>>>
>>>
>>>
>>>
>>> integration Backends/FS Protocols Consumers/Cloud Environments Tools 
>>> libgfapi
>>> bindings OS environment xfs smb qemu gdeploy java firewalld ext4 nfs
>>> openstack/cinder heketi python ufw btrfs swift
>>> openshift/docker/containers
>>> ruby selinux zfs
>>> aws
>>> go apparmor
>>>
>>> azure
>>>
>>>
>>>
>>>
>>> hadoop
>>>
>>>
>>> update major version upgrades minor version upgrades
>>>
>>>
>>>
>>> longevity a. memory leaks
>>> b. log accumulation
>>>
>>>
>>>
>>>
>>> distro packaging a. pkg build + smoke
>>> b. sysvinit/systemd
>>>
>>>
>>>
>>>
>>>
>>>
>>> I will send separate mails for each of the categories above highlighting
>>> plans for them.
>>>
>>> Use this thread to indicate addition/deletion/changes to this matrix.
>>> We will put this at gluster.org website once it is final.
>>>
>>> Thanks,
>>> Raghavendra Talur & MSV Bhat
>>>
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Gluster testing matrix

2015-12-21 Thread Raghavendra Talur 
On Thu, Dec 17, 2015 at 4:33 PM, Deepak Shetty  wrote:

> Where / How do you indicate whether the underlying GlusterFS is
> used/tested using fusemount or libgfapi method or both ?
>


There is no mechanism as of today to run the same test on GFAPI of FUSE
mount. Hence the tests explicitly choose the mount option.
The above line holds true for smoke, functional, regression and performance
categories.
If your question is regarding integration testing, it would depend entirely
on how the outside product likes to integrate with Gluster.



>
> On Wed, Nov 25, 2015 at 5:39 PM, Raghavendra Talur 
> wrote:
>
>> Hi All,
>>
>> Here is a table representing the current state of Gluster testing.
>>
>> * Things in green are categories for which we have some kind of testing
>> in place.
>> * Things in red are the ones which don't have any tests.
>> * Things in yellow are the ones which have no known tests or are not
>> managed by Gluster community.
>>
>>
>>
>> Test Category/Sub-Category
>>
>>
>>
>>
>>
>> smoke source build + Posix complaince + Dbench
>>
>>
>>
>>
>> functional tests/basic
>>
>>
>>
>>
>> regression tests/bugs
>>
>>
>>
>>
>> performance regression N/A
>>
>>
>>
>>
>> integration Backends/FS Protocols Consumers/Cloud Environments Tools libgfapi
>> bindings OS environment xfs smb qemu gdeploy java firewalld ext4 nfs
>> openstack/cinder heketi python ufw btrfs swift
>> openshift/docker/containers
>> ruby selinux zfs
>> aws
>> go apparmor
>>
>> azure
>>
>>
>>
>>
>> hadoop
>>
>>
>> update major version upgrades minor version upgrades
>>
>>
>>
>> longevity a. memory leaks
>> b. log accumulation
>>
>>
>>
>>
>> distro packaging a. pkg build + smoke
>> b. sysvinit/systemd
>>
>>
>>
>>
>>
>>
>> I will send separate mails for each of the categories above highlighting
>> plans for them.
>>
>> Use this thread to indicate addition/deletion/changes to this matrix.
>> We will put this at gluster.org website once it is final.
>>
>> Thanks,
>> Raghavendra Talur & MSV Bhat
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Front end for Gluster

2015-12-21 Thread Niels de Vos 
On Fri, Dec 18, 2015 at 10:22:08PM -0500, Prasanna Kumar Kalever wrote:
> Hello Team,
> 
> How many of us think an nursers based front for gluster will increase
> the ease of use ?
> 
> Find the attached Images that will show basic POC (see in ascending
> order)

There certainly are users that would like this. I have seen similar
interfaces written in shell scripts with 'dialog' before. It makes it
possible to give users ssh access to storage servers, where this tool
gets started instead of a shell. It allowed users to do minor tasks,
creating a volume for a new project (bricks would be pre-defined), make
a snapshot, enable access through Samba or NFS, and a few more things.
These users do not (need to) know any commandline tools, and the main
Linux admins would not need to get involved.

It will be interesting to see what users need for functionality in a
TUI. If this is written in a scripting language, it will be a nice way
for sysadmins to contribute.

Do you already have a project on github.com/gluster/?

Thanks,
Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Gluster REST - Management REST APIs for Glusterd 1.0

2015-12-21 Thread Aravinda 

Hi,

In the past I submitted a feature([1] and [2]) to provide REST interface 
to Gluster

CLI commands. I abandoned the patch because Glusterd 2.0 had plan to
include REST API support natively. Now I started again since other
projects like "skyrings"[3] is looking for REST API support for
Gluster.

Created a gist[4] to discuss the REST API formats, Please review and let
me know your thoughts. Document is still in WIP, will update the
document by next week.

[1] 
http://www.gluster.org/community/documentation/index.php/Features/rest-api

[2] http://review.gluster.org/#/c/7860/
[3] https://github.com/skyrings/
[4] https://gist.github.com/aravindavk/6961564b4b1d966b8845

--
regards
Aravinda

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Review request

2015-12-21 Thread Prasanna Kumar Kalever 
Hello Everyone,


It would be helpful if someone can review:

http://review.gluster.org/#/c/12709/
http://review.gluster.org/#/c/12963/
http://review.gluster.org/#/c/13002/


Thanks,
-Prasanna ​ 


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] few queries regarding file snapshot feature in gluster

2015-12-21 Thread Humble Devassy Chirammal 
Hi Prasanna,

>I am really thankful if some one gives more details about qemu-block
xlator,
I don't see enough documentation regarding this :(
>
Have you gone through
https://github.com/gluster/glusterfs/blob/master/doc/developer-guide/bd-xlator.md
? It has enough pointers to the bd xlator.

--Humble


On Mon, Dec 21, 2015 at 5:17 PM, Prasanna Kumar Kalever  wrote:

> Hi Team,
>
> I have few queries regarding file snapshot feature in gluster
>
> what are the limitations of Block device translator and qemu-block
> translator ?
> Are we using them some where ?
> Do we have plans to improve them ?
> Or someone have a design to implement file snapshot feature ?
>
> Are we just waiting till btrfs or zfs are fully stable ?
>
> I am really thankful if some one gives more details about qemu-block
> xlator,
> I don't see enough documentation regarding this :(
>
> Thanks,
> -Prasanna ​
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Gluster REST - Management REST APIs for Glusterd 1.0

2015-12-21 Thread Niels de Vos 
On Mon, Dec 21, 2015 at 04:21:13PM +0530, Aravinda wrote:
> Hi,
> 
> In the past I submitted a feature([1] and [2]) to provide REST interface to
> Gluster
> CLI commands. I abandoned the patch because Glusterd 2.0 had plan to
> include REST API support natively. Now I started again since other
> projects like "skyrings"[3] is looking for REST API support for
> Gluster.
> 
> Created a gist[4] to discuss the REST API formats, Please review and let
> me know your thoughts. Document is still in WIP, will update the
> document by next week.

Thanks for posting the doc! Could you follow the process that other
features follow? That means, send a patch to the Gerrit repoditory for
glusterfs-specs. It makes it easier to leave (in-line) comments.

Niels

> 
> [1]
> http://www.gluster.org/community/documentation/index.php/Features/rest-api
> [2] http://review.gluster.org/#/c/7860/
> [3] https://github.com/skyrings/
> [4] https://gist.github.com/aravindavk/6961564b4b1d966b8845
> 
> -- 
> regards
> Aravinda
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] few queries regarding file snapshot feature in gluster

2015-12-21 Thread Prasanna Kumar Kalever 
On Monday, December 21, 2015 5:44:24 PM, Humble Devassy Chirammal Wrote:
> Hi Prasanna,
> 
> >I am really thankful if some one gives more details about qemu-block
> xlator,
> I don't see enough documentation regarding this :(
> >
> Have you gone through
> https://github.com/gluster/glusterfs/blob/master/doc/developer-guide/bd-xlator.md
> ? It has enough pointers to the bd xlator.

Hi Humble,
I am referring to qemu-block xlator here. I have seen this in my local repo

Thanks,
-Prasanna

> 
> --Humble
> 
> 
> On Mon, Dec 21, 2015 at 5:17 PM, Prasanna Kumar Kalever  > wrote:
> 
> > Hi Team,
> >
> > I have few queries regarding file snapshot feature in gluster
> >
> > what are the limitations of Block device translator and qemu-block
> > translator ?
> > Are we using them some where ?
> > Do we have plans to improve them ?
> > Or someone have a design to implement file snapshot feature ?
> >
> > Are we just waiting till btrfs or zfs are fully stable ?
> >
> > I am really thankful if some one gives more details about qemu-block
> > xlator,
> > I don't see enough documentation regarding this :(
> >
> > Thanks,
> > -Prasanna ​
> >
> >
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] few queries regarding file snapshot feature in gluster

2015-12-21 Thread Prasanna Kumar Kalever 
Hi Team,

I have few queries regarding file snapshot feature in gluster

what are the limitations of Block device translator and qemu-block translator ?
Are we using them some where ?
Do we have plans to improve them ?
Or someone have a design to implement file snapshot feature ? 

Are we just waiting till btrfs or zfs are fully stable ? 

I am really thankful if some one gives more details about qemu-block xlator,
I don't see enough documentation regarding this :(

Thanks,
-Prasanna ​ 


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Front end for Gluster

2015-12-21 Thread Prasanna Kumar Kalever 
On Monday, December 21, 2015 3:41:04 PM, Niels de Vos wrote:
> On Fri, Dec 18, 2015 at 10:22:08PM -0500, Prasanna Kumar Kalever wrote:
> > Hello Team,
> > 
> > How many of us think an nursers based front for gluster will increase
> > the ease of use ?
> > 
> > Find the attached Images that will show basic POC (see in ascending
> > order)
> 
> There certainly are users that would like this. I have seen similar
> interfaces written in shell scripts with 'dialog' before. It makes it
> possible to give users ssh access to storage servers, where this tool
> gets started instead of a shell. It allowed users to do minor tasks,
> creating a volume for a new project (bricks would be pre-defined), make
> a snapshot, enable access through Samba or NFS, and a few more things.
> These users do not (need to) know any commandline tools, and the main
> Linux admins would not need to get involved.
> 
> It will be interesting to see what users need for functionality in a
> TUI. If this is written in a scripting language, it will be a nice way
> for sysadmins to contribute.

thank you Niels, I have used 'dialog' for POC,
I think we both are dancing for the same music here :)

> 
> Do you already have a project on github.com/gluster/?

haven't yet created one, before doing that I just thought of watching
communities reaction

-Prasanna

> 
> Thanks,
> Niels
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Quota-2

2015-12-21 Thread Shyam 

On 12/20/2015 10:57 PM, Vijaikumar Mallikarjuna wrote:



On Fri, Dec 18, 2015 at 8:28 PM, Shyam > wrote:



On 12/18/2015 04:00 AM, Vijaikumar Mallikarjuna wrote:

Hi All,

Here is the summary of discussion we had today on Quota-v2

Project, user and group quotas will use the same logic of
accounting the
usage

Quota-v2 should be compatible with both DHT-v1 and DHT-v2

Project quotas will use gfid of the given path as the project-id.
  each inode will have a associated project-id which needs to be
embedded within inode.
  when creating new file, it will inherit project-id from
its parent
inode.
  In case if parent inode doesn't contain project-id, then there
should be a mechanism to
  find the project-id given a gfid, so back-pointers can
solve this
problem


Why would the parent not contain a project-id? and if it does not
contain a project-id, why would you need to find a project-id?

What I can visualize is that, the parent is not yet part of a quota
project, hence it does not contain a project-id. When this becomes a
part of some quota restriction it would start getting a quota. This
seems to be one case where the project-id would be missing, but by
choice.

What am I missing here?

There are two scenarios where project-id can be missing
1) When quota is enabled on a pre-existing data,


I would assume there would be a sub-tree walk here that marks the 
existing data with the project-id and hence start accounting. As a 
result in this case we should not need to traverse when creating an 
entry just to hunt for a possible project-id, the sub-tree walk would 
get to this entry during its walk.



2) Directory created when one of the brick is down


Again, this should be a part of the heal, i.e when the directory is 
created on the brick that was down, it should get marked with the right 
inode information (project-id in this case). Further objects can be 
created under this directory only when the directory itself is created, 
as a result, if we tackle the problem during directory heal/creation on 
the down brick, we should not have to traverse backward to get the 
potential project-id.


Thoughts?



Thanks,
Vijay


  which xlator DHT/marker will set the project-id in the
inode? this
needs to be decided
User and group quotas will use uid and gid to account the usage

Quota has below set of operation which should be performed as a
single
transaction
read current size
read current contribution
update delta to the contribution
update size to user/project inode
In the current directory quota, to make this transaction crash
consistent we use a mechanism of setting dirty flag in a parent
inode.
This mechanism will not work efficiently with project quotas.
Journaling
will be the good solution for crash-consistency.

Quota 2 depends on:
back-pointers: to find project-id from gfid
journaling: for crash consistency of accounting


Thanks,
Vijay



___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Quota-2

2015-12-21 Thread Venky Shankar 



Venky Shankar wrote:



Shyam wrote:

On 12/19/2015 01:13 AM, Venky Shankar wrote:



Shyam wrote:



On 12/18/2015 04:00 AM, Vijaikumar Mallikarjuna wrote:

Hi All,

Here is the summary of discussion we had today on Quota-v2

Project, user and group quotas will use the same logic of accounting
the
usage

Quota-v2 should be compatible with both DHT-v1 and DHT-v2

Project quotas will use gfid of the given path as the project-id.
each inode will have a associated project-id which needs to be
embedded within inode.
when creating new file, it will inherit project-id from its parent
inode.
In case if parent inode doesn't contain project-id, then there
should be a mechanism to
find the project-id given a gfid, so back-pointers can solve this
problem


Why would the parent not contain a project-id? and if it does not
contain a project-id, why would you need to find a project-id?


Updating project-id's for all children for a given directory on which a
project-id is set would required scanning. If we could figure
out the project-id for a given inode using back-pointers (closest
ancestor for which a project-id is set) then we'd not need the crawl and
update.


For existing directories when a quota is set, we need to do the scan and
set/update the quota information, right? This is unavoidable as far as I
can see.


I was more into trying to save the sub-tree update when a project-id is
set on a directory. If (with current dht) we could figure out the
project-id for the closest project-id set ancestor using back-pointers
(or whatever..) then we could possibly avoid the scan + update.


Vijaikumar mentioned that XFS does the scan + update during project-id 
set, however it's pretty fast - however, that's not the case with Gluster.


Correct me if I'm wrong please.





For a new entry, as responded in the other mail on this thread, if the
parent is not yet marked with a project-id then the child will inherit
the same when the scanner updates the project-id for the parent, till
then there is no need to account.



With DHT2, such a mechanism would query each MDS. For current DHT, it
might still be good enough.


With DHT2 the scanner (for updating quota information for pre-existing
directories) may need to split the work up and perform the operation. A
crude thought at the moment would be,
- Set the project-id for the grandparent where the quota enforcement
starts
- Set the pj-id for the leaf objects for this directory, and set the
pj-id for the directories under this grandparent, but take up marking
leaves of these sub-directories as tasks in the other MDS stack
(wherever they belong, i.e same MDS or a different one).





What I can visualize is that, the parent is not yet part of a quota
project, hence it does not contain a project-id. When this becomes a
part of some quota restriction it would start getting a quota. This
seems to be one case where the project-id would be missing, but by
choice.

What am I missing here?


which xlator DHT/marker will set the project-id in the inode? this
needs to be decided
User and group quotas will use uid and gid to account the usage

Quota has below set of operation which should be performed as a single
transaction
read current size
read current contribution
update delta to the contribution
update size to user/project inode
In the current directory quota, to make this transaction crash
consistent we use a mechanism of setting dirty flag in a parent inode.
This mechanism will not work efficiently with project quotas.
Journaling
will be the good solution for crash-consistency.

Quota 2 depends on:
back-pointers: to find project-id from gfid
journaling: for crash consistency of accounting


Thanks,
Vijay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Quota-2

2015-12-21 Thread Shyam 

On 12/19/2015 01:13 AM, Venky Shankar wrote:



Shyam wrote:



On 12/18/2015 04:00 AM, Vijaikumar Mallikarjuna wrote:

Hi All,

Here is the summary of discussion we had today on Quota-v2

Project, user and group quotas will use the same logic of accounting the
usage

Quota-v2 should be compatible with both DHT-v1 and DHT-v2

Project quotas will use gfid of the given path as the project-id.
each inode will have a associated project-id which needs to be
embedded within inode.
when creating new file, it will inherit project-id from its parent
inode.
In case if parent inode doesn't contain project-id, then there
should be a mechanism to
find the project-id given a gfid, so back-pointers can solve this
problem


Why would the parent not contain a project-id? and if it does not
contain a project-id, why would you need to find a project-id?


Updating project-id's for all children for a given directory on which a
project-id is set would required scanning. If we could figure
out the project-id for a given inode using back-pointers (closest
ancestor for which a project-id is set) then we'd not need the crawl and
update.


For existing directories when a quota is set, we need to do the scan and 
set/update the quota information, right? This is unavoidable as far as I 
can see.


For a new entry, as responded in the other mail on this thread, if the 
parent is not yet marked with a project-id then the child will inherit 
the same when the scanner updates the project-id for the parent, till 
then there is no need to account.




With DHT2, such a mechanism would query each MDS. For current DHT, it
might still be good enough.


With DHT2 the scanner (for updating quota information for pre-existing 
directories) may need to split the work up and perform the operation. A 
crude thought at the moment would be,

- Set the project-id for the grandparent where the quota enforcement starts
- Set the pj-id for the leaf objects for this directory, and set the 
pj-id for the directories under this grandparent, but take up marking 
leaves of these sub-directories as tasks in the other MDS stack 
(wherever they belong, i.e same MDS or a different one).






What I can visualize is that, the parent is not yet part of a quota
project, hence it does not contain a project-id. When this becomes a
part of some quota restriction it would start getting a quota. This
seems to be one case where the project-id would be missing, but by
choice.

What am I missing here?


which xlator DHT/marker will set the project-id in the inode? this
needs to be decided
User and group quotas will use uid and gid to account the usage

Quota has below set of operation which should be performed as a single
transaction
read current size
read current contribution
update delta to the contribution
update size to user/project inode
In the current directory quota, to make this transaction crash
consistent we use a mechanism of setting dirty flag in a parent inode.
This mechanism will not work efficiently with project quotas. Journaling
will be the good solution for crash-consistency.

Quota 2 depends on:
back-pointers: to find project-id from gfid
journaling: for crash consistency of accounting


Thanks,
Vijay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Quota-2

2015-12-21 Thread Venky Shankar 



Shyam wrote:

On 12/19/2015 01:13 AM, Venky Shankar wrote:



Shyam wrote:



On 12/18/2015 04:00 AM, Vijaikumar Mallikarjuna wrote:

Hi All,

Here is the summary of discussion we had today on Quota-v2

Project, user and group quotas will use the same logic of accounting
the
usage

Quota-v2 should be compatible with both DHT-v1 and DHT-v2

Project quotas will use gfid of the given path as the project-id.
each inode will have a associated project-id which needs to be
embedded within inode.
when creating new file, it will inherit project-id from its parent
inode.
In case if parent inode doesn't contain project-id, then there
should be a mechanism to
find the project-id given a gfid, so back-pointers can solve this
problem


Why would the parent not contain a project-id? and if it does not
contain a project-id, why would you need to find a project-id?


Updating project-id's for all children for a given directory on which a
project-id is set would required scanning. If we could figure
out the project-id for a given inode using back-pointers (closest
ancestor for which a project-id is set) then we'd not need the crawl and
update.


For existing directories when a quota is set, we need to do the scan and
set/update the quota information, right? This is unavoidable as far as I
can see.


I was more into trying to save the sub-tree update when a project-id is 
set on a directory. If (with current dht) we could figure out the 
project-id for the closest project-id set ancestor using back-pointers 
(or whatever..) then we could possibly avoid the scan + update.




For a new entry, as responded in the other mail on this thread, if the
parent is not yet marked with a project-id then the child will inherit
the same when the scanner updates the project-id for the parent, till
then there is no need to account.



With DHT2, such a mechanism would query each MDS. For current DHT, it
might still be good enough.


With DHT2 the scanner (for updating quota information for pre-existing
directories) may need to split the work up and perform the operation. A
crude thought at the moment would be,
- Set the project-id for the grandparent where the quota enforcement starts
- Set the pj-id for the leaf objects for this directory, and set the
pj-id for the directories under this grandparent, but take up marking
leaves of these sub-directories as tasks in the other MDS stack
(wherever they belong, i.e same MDS or a different one).





What I can visualize is that, the parent is not yet part of a quota
project, hence it does not contain a project-id. When this becomes a
part of some quota restriction it would start getting a quota. This
seems to be one case where the project-id would be missing, but by
choice.

What am I missing here?


which xlator DHT/marker will set the project-id in the inode? this
needs to be decided
User and group quotas will use uid and gid to account the usage

Quota has below set of operation which should be performed as a single
transaction
read current size
read current contribution
update delta to the contribution
update size to user/project inode
In the current directory quota, to make this transaction crash
consistent we use a mechanism of setting dirty flag in a parent inode.
This mechanism will not work efficiently with project quotas.
Journaling
will be the good solution for crash-consistency.

Quota 2 depends on:
back-pointers: to find project-id from gfid
journaling: for crash consistency of accounting


Thanks,
Vijay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel