Re: [Gluster-devel] quota-rename.t core in netbsd

[Sanoj Unnikrishnan]

This is a memory overrun issue.

I was not able to fully RCA this issue. In particular i had trouble trying
to run gluster on netbsd setup.

will pick this up later if it is deemed as priority.



(gdb)

#0  0xbb40b4b7 in ?? ()

#1  0xbb756685 in synctask_destroy (task=0xb6722030) at
/home/jenkins/root/workspace/netbsd7-regression/libglusterfs/src/syncop.c:391

#2  0xbb756701 in synctask_done (task=0xb6722030) at
/home/jenkins/root/workspace/netbsd7-regression/libglusterfs/src/syncop.c:409

#3  0xbb756fed in synctask_switchto (task=0xb6722030) at
/home/jenkins/root/workspace/netbsd7-regression/libglusterfs/src/syncop.c:668

#4  0xbb75709b in syncenv_processor (thdata=)

at
/home/jenkins/root/workspace/netbsd7-regression/libglusterfs/src/syncop.c:699

(gdb) frame 1

#1  0xbb756685 in synctask_destroy (task=0xb6722030) at
/home/jenkins/root/workspace/netbsd7-regression/libglusterfs/src/syncop.c:391

391 
/home/jenkins/root/workspace/netbsd7-regression/libglusterfs/src/syncop.c:
No such file or directory.

(gdb) p *task

$1 = {all_tasks = {next = 0xb6722030, prev = 0xb6722030}, env = 0xbb1a9030,
xl = 0xb9901030, frame = 0x0, opframe = 0xb6702100, synccbk = 0xb9aa0849
,

 syncfn = 0xb9aa297a , state = SYNCTASK_DONE,
opaque = 0xb670b0b0, stack = 0xb6724030, woken = 0, slept = 0, ret = 0, uid
= 0, gid = 0, ctx = {

uc_flags = 524335, uc_link = 0x0, uc_sigmask = {__bits = {4294897751,
4294967295, 4294967295, 4294967295}}, uc_stack = {ss_sp = 0xbf80,
ss_size = 270336, ss_flags = 0},

uc_mcontext = {__gregs = {179, 171, 31, 31, -1195381232, -1234128720,
-1234010112, -1234010176, -1149368040, -1155886264, -1234034576, 0, 3, 2,
-1149934353, 23, 2097814, -1234010160,

   31}, __fpregs = {__fp_reg_set = {__fpchip_state = {__fp_state =
{16778111, 0, -1180420687, 23, -1195379520, 31, 8064, 65471, 0 }}, __fp_xmm_state = {

   __fp_xmm =
"\177\003\000\001\000\000\000\000\261\065��\027\000\000\000�\364\277�\037\000\000\000\200\037\000\000\277\377",
'\000' , "�\005@", '\000' , "�\005@",
'\000' ...}, __fp_fpregs = {16778111, 0, -1180420687,
23, -1195379520, 31, 8064, 65471, 0 , -268435456, 16389,
0, 0, -1610612736,

   16389, 0 , 895, 0 }},
__fp_pad = {0 }}, _mc_tlsbase = -1154730944}, __uc_pad =
{0, 0, 0, 0}}, proc = 0xbb1a9344, mutex = {

ptm_magic = 0, ptm_errorcheck = 0 '\000', ptm_pad1 = "\000\000",
ptm_interlock = 0 '\000', ptm_pad2 = "\000\000", ptm_owner = 0x0,
ptm_waiters = 0x0, ptm_recursed = 0,

ptm_spare2 = 0x0}, cond = {ptc_magic = 0, ptc_lock = 0 '\000',
ptc_waiters = {ptqh_first = 0x0, ptqh_last = 0x0}, ptc_mutex = 0x0,
ptc_private = 0x0}, done = 0, waitq = {

next = 0xb67223b4, prev = 0xb67223b4}, btbuf = "(--> 0xbb7564d1 (-->
 (--> at (--> /build/install/lib/libglusterfs.so.0
", '\000' }


(gdb) p/x *(struct mem_header*)(task->stack - sizeof(struct mem_header))

$10 = {type = 0xbb6cd33f, size = 0x1, mem_acct = 0xb992f000, magic =
0xcafebabe, padding = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}

=>Header magic is intact

(gdb) x/5x (task->stack)

0xb6724030: 0x  0x  0x  0x

0xb6724040: 0x

=>Trailer magic is Overwritten

Regards,

Sanoj

On Thu, Oct 13, 2016 at 10:22 AM, Raghavendra Gowdappa 
wrote:

> +Muthu, +Sanoj
>
> Sure Vijay. One of us will take a look.
>
> - Original Message -
> > From: "Vijay Bellur" 
> > To: "Gluster Devel" , "Raghavendra Gowdappa"
> 
> > Sent: Wednesday, October 5, 2016 11:25:34 PM
> > Subject: quota-rename.t core in netbsd
> >
> > Hi All,
> >
> > I observed a few crashes due to quota-rename.t in netbsd regression
> > runs [1] [2].  Raghavendra - can you please take a look when you get a
> > chance?
> >
> > The core files and logs cannot be downloaded from the URLs in jenkins
> > job console history for NetBSD. I have logged a bug [3] on the
> > infrastructure for that.
> >
> > Thanks,
> > Vijay
> >
> > [1] https://build.gluster.org/job/netbsd7-regression/942/consoleFull
> >
> > [2]  https://build.gluster.org/job/netbsd7-regression/945/console
> >
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1382097
> >
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Gluster Developer Summit 2016 Notes

[Amye Scavarda]

Notes from our Gluster Developer Summit 2016 in Berlin!

Videos
Slides
Flickr Group
Public Etherpad
Bootstrapping Challenge

All of the videos from Gluster Developer Summit are now live on our YouTube
channel, and slides are available in our Slideshare accounts. We've also
created a Flickr group, please add your photos of the event!

https://www.youtube.com/user/GlusterCommunity
http://www.slideshare.net/GlusterCommunity
https://www.flickr.com/groups/glusterdevelopersummit2016/

We've also got a public etherpad for our comments from the event:
https://public.pad.fsfe.org/p/gluster-developer-summit-2016

Please feel free to add to this and help keep our momentum from this event!
I'm looking for the community maintainers to take a strong hand in here to
be able to tell us what they're focusing on this from this event over the
next three months.

One thing that we didn't get to that I wanted to was a Community Bootstrap
Challenge, so let's do this as a hangout after the Community Meeting on
November 2nd. I'll send out a separate email on this describing the event,
and we'll all join in at 1pm UTC.

Anything I missed?

Happy to take suggestions and comments about what else we'd want to see in
a Gluster Developer Summit!

-- amye

-- 
Amye Scavarda | a...@redhat.com | Gluster Community Lead
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Regarding merge window for the approaching GlusterFS-3.7.17 release

[Samikshan Bairagya]

Hi all,

GlusterFS-3.7.17 is on target to be released on October 30th (Sunday).

In preparation for the release, maintainers would need to merge all 
changes into release-3.7 before Wednesday (October 26). This would give 
us ~4days to test and verify the build.


Thanks and Regards,

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

[Gluster-devel] Input/output error when files in .shard folder are deleted

[qingwei wei]

Hi,

I am currently running a simple gluster setup using one server node
with multiple disks. I realize that if i delete away all the .shard
files in one replica in the backend, my application (dd) will report
Input/Output error even though i have 3 replicas.

My gluster version is 3.7.16

gluster volume file

Volume Name: testHeal
Type: Replicate
Volume ID: 26d16d7f-bc4f-44a6-a18b-eab780d80851
Status: Started
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: 192.168.123.4:/mnt/sdb_mssd/testHeal2
Brick2: 192.168.123.4:/mnt/sde_mssd/testHeal2
Brick3: 192.168.123.4:/mnt/sdd_mssd/testHeal2
Options Reconfigured:
cluster.self-heal-daemon: on
features.shard-block-size: 16MB
features.shard: on
performance.readdir-ahead: on

dd error

[root@fujitsu05 .shard]# dd of=/home/test if=/mnt/fuseMount/ddTest
bs=16M count=20 oflag=direct
dd: error reading ‘/mnt/fuseMount/ddTest’: Input/output error
1+0 records in
1+0 records out
16777216 bytes (17 MB) copied, 0.111038 s, 151 MB/s

in the .shard folder where i deleted all the .shard file, i can see
one .shard file is recreated

getfattr -d -e hex -m.  9061198a-eb7e-45a2-93fb-eb396d1b2727.1
# file: 9061198a-eb7e-45a2-93fb-eb396d1b2727.1
trusted.afr.testHeal-client-0=0x00010001
trusted.afr.testHeal-client-2=0x00010001
trusted.gfid=0x41b653f7daa14627b1f91f9e8554ddde

However, the gfid is not the same compare to the other replicas

getfattr -d -e hex -m.  9061198a-eb7e-45a2-93fb-eb396d1b2727.1
# file: 9061198a-eb7e-45a2-93fb-eb396d1b2727.1
trusted.afr.dirty=0x
trusted.afr.testHeal-client-1=0x
trusted.bit-rot.version=0x0300580dde99000e5e5d
trusted.gfid=0x9ee5c5eed7964a6cb9ac1a1419de5a40

Is this consider a bug?

Regards,

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

Re: [Gluster-devel] FW: GlusterFS native api

[Niels de Vos]

> On Wed, Oct 19, 2016 at 9:31 PM, Simon Turcotte-Langevin 
> >
>  wrote:
> Hello Pranith,
> 
> We’re still investigating possible optimizations to our platform, and
> we were wondering: is the fuse translator very slow compared to native
> glusterfs operations?
> Since we’re using a subset of operations available through fuse, we
> could create an abstraction layer from gluster’s native api instead of
> relying on a fuse mount. Would that increase our performance/stability
> by a lot?

Hello Simon,

We offer a shared library that other applications can use to talk to the
Gluster Volumes. This (C) library is called libgfapi.so and can be
installed with the glusterfs-api RPM (or similar for other
distributions). The interface is described in it's main header file [0]
from the glusterfs-api-devel RPM.

The glusterfs sources have a few examples [1] and small applications for
regression testing [2][3]. There are also several projects that use the
library, you cool look at those for examples as well:
 - glusterfs-coreutils [4]
 - Samba/vfs_glusterfs [5]
 - NFS-Ganesha/FSAL_GLUSTER [6]

Under the Gluster organization in GitHub you can find bindings to
different languages [7].

If you exaplain a litte more about the application that could use
libgfapi for accessing Gluster, we can advise you on how we'd
approach/design the access interface. Important information includes
access patterns, i/o operations and muti-process/threading needs.

HTH,
Niels


0. https://github.com/gluster/glusterfs/blob/master/api/src/glfs.h
1. https://github.com/gluster/glusterfs/blob/master/api/examples/glfsxmp.c
2. https://github.com/gluster/glusterfs/tree/master/tests/basic/gfapi
3. https://github.com/gluster/glusterfs/tree/master/tests/bugs/gfapi
4. https://github.com/gluster/glusterfs-coreutils
5. 
https://git.samba.org/?p=samba.git;a=blob;f=source3/modules/vfs_glusterfs.c;hb=HEAD
6. https://github.com/nfs-ganesha/nfs-ganesha/tree/next/src/FSAL/FSAL_GLUSTER
7. https://github.com/gluster/?query=api


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

Re: [Gluster-devel] Possible problem introduced by http://review.gluster.org/15573

[Xavier Hernandez]

Hi Soumya,

On 21/10/16 16:15, Soumya Koduri wrote:



On 10/21/2016 06:35 PM, Soumya Koduri wrote:

Hi Xavi,

On 10/21/2016 12:57 PM, Xavier Hernandez wrote:

Looking at the code, I think that the added fd_unref() should only be
called if the fop preparation fails. Otherwise the callback already
unreferences the fd.

Code flow:

* glfs_fsync_async_common() takes an fd ref and calls STACK_WIND passing
that fd.
* Just after that a ref is released.
* When glfs_io_async_cbk() is called another ref is released.

Note that if fop preparation fails, a single fd_unref() is called, but
on success two fd_unref() are called.


Sorry for the inconvenience caused. I think its patch#15573 hasn't
caused the problem but has highlighted another ref leak in the code.

From the code I see that glfs_io_async_cbk() does fd_unref (glfd->fd)
but not the fd passed in STACK_WIND_COOKIE() of the fop.

If I take any fop, for eg.,
glfs_fsync_common() {

   fd = glfs_resolve_fd (glfd->fs, subvol, glfd);


}

Here in glfs_resolve_fd ()

fd_t *
__glfs_resolve_fd (struct glfs *fs, xlator_t *subvol, struct glfs_fd
*glfd)
{
fd_t *fd = NULL;

if (glfd->fd->inode->table->xl == subvol)
return fd_ref (glfd->fd);


Here we can see that  we are taking extra ref additional to the

ref already taken for glfd->fd. That means the caller of this function
needs to fd_unref(fd) irrespective of subsequent fd_unref (glfd->fd).

fd = __glfs_migrate_fd (fs, subvol, glfd);
if (!fd)
return NULL;


if (subvol == fs->active_subvol) {
fd_unref (glfd->fd);
glfd->fd = fd_ref (fd);
}


I think the issue is here during graph_switch(). You have

mentioned as well that the crash happens post graph_switch. Maybe here
we are missing an extra ref to be taken for fd additional to glfd->fd. I
need to look through __glfs_migrate_fd() to confirm that. But these are
my initial thoughts.


Looking into this, I think we should fix glfs_io_async_cbk() not to
fd_unref(glfd->fd). glfd->fd should be active though out the lifetime of
glfd (i.e, until it is closed). Thoughts?


I don't know gfapi internals in deep, but at first sight I think this 
would be the right think to do. Assuming that glfd will keep a reference 
to the fd until it's destroyed, and that a glfd reference is taken 
during the lifetime of each request that needs it, the fd_unref() in 
glfd_io_async_cbk() seems unnecessary. I think it was there just to 
release the fd acquired if glfs_resolve_fd(), but it's better to place 
it where it's now.


Another question is if we really need to take an additional reference in 
glfs_resolve_fd() ?


Can an fd returned by this function live more time than the associated 
glfd in some circumstances ?



Also could you please check if it is the second/subsequent fsync_async()
call which results in crash?


I'll try to test it as soon as possible, but this is on a server that we 
need to put in production very soon and we have decided to go with fuse 
for now. We'll have a lot of work to do this week. Once I have some free 
time I'll build a test environment to check it, probably next week.


Xavi



Thanks,
Soumya



Please let me know your comments.

Thanks,
Soumya




Xavi

On 21/10/16 09:03, Xavier Hernandez wrote:

Hi,

I've just tried Gluster 3.8.5 with Proxmox using gfapi and I
consistently see a crash each time an attempt to connect to the volume
is made.

The backtrace of the crash shows this:

#0  pthread_spin_lock () at
../nptl/sysdeps/x86_64/pthread_spin_lock.S:24
#1  0x7fe5345776a5 in fd_unref (fd=0x7fe523f7205c) at fd.c:553
#2  0x7fe53482ba18 in glfs_io_async_cbk (op_ret=,
op_errno=0, frame=, cookie=0x7fe526c67040,
iovec=iovec@entry=0x0, count=count@entry=0)
at glfs-fops.c:839
#3  0x7fe53482beed in glfs_fsync_async_cbk (frame=,
cookie=, this=, op_ret=,
op_errno=,
prebuf=, postbuf=0x7fe5217fe890, xdata=0x0) at
glfs-fops.c:1382
#4  0x7fe520be2eb7 in ?? () from
/usr/lib/x86_64-linux-gnu/glusterfs/3.8.5/xlator/debug/io-stats.so
#5  0x7fe5345d118a in default_fsync_cbk (frame=0x7fe52ceef3ac,
cookie=0x560ef95398e8, this=0x8, op_ret=0, op_errno=0, prebuf=0x1,
postbuf=0x7fe5217fe890, xdata=0x0) at defaults.c:1508
#6  0x7fe5345d118a in default_fsync_cbk (frame=0x7fe52ceef204,
cookie=0x560ef95398e8, this=0x8, op_ret=0, op_errno=0, prebuf=0x1,
postbuf=0x7fe5217fe890, xdata=0x0) at defaults.c:1508
#7  0x7fe525f78219 in dht_fsync_cbk (frame=0x7fe52ceef2d8,
cookie=0x560ef95398e8, this=0x0, op_ret=0, op_errno=0,
prebuf=0x7fe5217fe820, postbuf=0x7fe5217fe890, xdata=0x0)
at dht-inode-read.c:873
#8  0x7fe5261bbc7f in client3_3_fsync_cbk (req=0x7fe525f78030
, iov=0x7fe526c61040, count=8,
myframe=0x7fe52ceef130) at
client-rpc-fops.c:975
#9  0x7fe5343201f0 in rpc_clnt_handle_reply (clnt=0x18,
clnt@entry=0x7fe526fafac0, pollin=0x7fe526c3a1c0) at rpc-clnt.c:791
#10 0x7fe53432056c in rpc_clnt_notify (trans=,

Re: [Gluster-devel] Possible problem introduced by http://review.gluster.org/15573

[Xavier Hernandez]

On 21/10/16 15:05, Soumya Koduri wrote:

Hi Xavi,

On 10/21/2016 12:57 PM, Xavier Hernandez wrote:

Looking at the code, I think that the added fd_unref() should only be
called if the fop preparation fails. Otherwise the callback already
unreferences the fd.

Code flow:

* glfs_fsync_async_common() takes an fd ref and calls STACK_WIND passing
that fd.
* Just after that a ref is released.
* When glfs_io_async_cbk() is called another ref is released.

Note that if fop preparation fails, a single fd_unref() is called, but
on success two fd_unref() are called.


Sorry for the inconvenience caused. I think its patch#15573 hasn't
caused the problem but has highlighted another ref leak in the code.

From the code I see that glfs_io_async_cbk() does fd_unref (glfd->fd)
but not the fd passed in STACK_WIND_COOKIE() of the fop.


I think it's the same because the fd passed in STACK_WIND_COOKIE() also 
comes from glfd->fd.




If I take any fop, for eg.,
glfs_fsync_common() {

   fd = glfs_resolve_fd (glfd->fs, subvol, glfd);


}

Here in glfs_resolve_fd ()

fd_t *
__glfs_resolve_fd (struct glfs *fs, xlator_t *subvol, struct glfs_fd *glfd)
{
fd_t *fd = NULL;

if (glfd->fd->inode->table->xl == subvol)
return fd_ref (glfd->fd);


Here we can see that  we are taking extra ref additional to the

ref already taken for glfd->fd. That means the caller of this function
needs to fd_unref(fd) irrespective of subsequent fd_unref (glfd->fd).


I agree here. This additional ref must be released somewhere.



fd = __glfs_migrate_fd (fs, subvol, glfd);
if (!fd)
return NULL;


if (subvol == fs->active_subvol) {
fd_unref (glfd->fd);
glfd->fd = fd_ref (fd);
}


I think the issue is here during graph_switch(). You have

mentioned as well that the crash happens post graph_switch. Maybe here
we are missing an extra ref to be taken for fd additional to glfd->fd. I
need to look through __glfs_migrate_fd() to confirm that. But these are
my initial thoughts.


I think this is ok. The fd returned by __glfs_migrate_fd() already has a 
reference. We release the fd currently assigned to glfd->fd (that has 
only one reference) and assign the new fd to it, taking an additional 
reference (two in total) like in the previous case.


Xavi



Please let me know your comments.

Thanks,
Soumya




Xavi

On 21/10/16 09:03, Xavier Hernandez wrote:

Hi,

I've just tried Gluster 3.8.5 with Proxmox using gfapi and I
consistently see a crash each time an attempt to connect to the volume
is made.

The backtrace of the crash shows this:

#0  pthread_spin_lock () at
../nptl/sysdeps/x86_64/pthread_spin_lock.S:24
#1  0x7fe5345776a5 in fd_unref (fd=0x7fe523f7205c) at fd.c:553
#2  0x7fe53482ba18 in glfs_io_async_cbk (op_ret=,
op_errno=0, frame=, cookie=0x7fe526c67040,
iovec=iovec@entry=0x0, count=count@entry=0)
at glfs-fops.c:839
#3  0x7fe53482beed in glfs_fsync_async_cbk (frame=,
cookie=, this=, op_ret=,
op_errno=,
prebuf=, postbuf=0x7fe5217fe890, xdata=0x0) at
glfs-fops.c:1382
#4  0x7fe520be2eb7 in ?? () from
/usr/lib/x86_64-linux-gnu/glusterfs/3.8.5/xlator/debug/io-stats.so
#5  0x7fe5345d118a in default_fsync_cbk (frame=0x7fe52ceef3ac,
cookie=0x560ef95398e8, this=0x8, op_ret=0, op_errno=0, prebuf=0x1,
postbuf=0x7fe5217fe890, xdata=0x0) at defaults.c:1508
#6  0x7fe5345d118a in default_fsync_cbk (frame=0x7fe52ceef204,
cookie=0x560ef95398e8, this=0x8, op_ret=0, op_errno=0, prebuf=0x1,
postbuf=0x7fe5217fe890, xdata=0x0) at defaults.c:1508
#7  0x7fe525f78219 in dht_fsync_cbk (frame=0x7fe52ceef2d8,
cookie=0x560ef95398e8, this=0x0, op_ret=0, op_errno=0,
prebuf=0x7fe5217fe820, postbuf=0x7fe5217fe890, xdata=0x0)
at dht-inode-read.c:873
#8  0x7fe5261bbc7f in client3_3_fsync_cbk (req=0x7fe525f78030
, iov=0x7fe526c61040, count=8, myframe=0x7fe52ceef130) at
client-rpc-fops.c:975
#9  0x7fe5343201f0 in rpc_clnt_handle_reply (clnt=0x18,
clnt@entry=0x7fe526fafac0, pollin=0x7fe526c3a1c0) at rpc-clnt.c:791
#10 0x7fe53432056c in rpc_clnt_notify (trans=,
mydata=0x7fe526fafaf0, event=, data=0x7fe526c3a1c0) at
rpc-clnt.c:962
#11 0x7fe53431c8a3 in rpc_transport_notify (this=,
event=, data=) at rpc-transport.c:541
#12 0x7fe5283e8d96 in socket_event_poll_in (this=0x7fe526c69440) at
socket.c:2267
#13 0x7fe5283eaf37 in socket_event_handler (fd=,
idx=5, data=0x7fe526c69440, poll_in=1, poll_out=0, poll_err=0) at
socket.c:2397
#14 0x7fe5345ab3f6 in event_dispatch_epoll_handler
(event=0x7fe5217fecc0, event_pool=0x7fe526ca2040) at event-epoll.c:571
#15 event_dispatch_epoll_worker (data=0x7fe527c0f0c0) at
event-epoll.c:674
#16 0x7fe5324140a4 in start_thread (arg=0x7fe5217ff700) at
pthread_create.c:309
#17 0x7fe53214962d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

The fd being unreferenced contains this:

(gdb) print *fd
$6 = {
  pid = 97649,
  flags = 2,
  refcount = 0,
  inode_list = {
 

Re: [Gluster-devel] New commands for supporting add/remove brick and rebalance on tiered volume

[Hari Gowtham]

I forgot to mention that with the first approach we need a separate tier 
add brick parser. If we add these changes to the existing add-brick parser, 
then the major changes are :
The word count for normal add-brick and tier-add-brick are totally different.
As the word count messes up, we need to put tier-add-brick parsing into a 
separate 
function now itself. 

We can support multiple tier even with the second approach. this doesn't need 
much 
changes in parsing. the existing one can be used with minor tweaks. and can be 
rewritten 
any time to separate it from add-brick parsing.

else if (!strcmp(words[3], "add-hot-brick")) {
 ret = do_cli_cmd_volume_add_hotbr_tier (state, word,
 words, wordcount-1);
 goto out;

This is the only part that will need change. We need to add similar 
function so that in that function we can set the dict to mention whether its 
hot or cold, or in this case the tier-id. 

The tier-id wont need a huge change in the cli part as it is already designed 
similarly 
to add hot or cold brick. Based on this dict value we are making changes to the 
volfile.

Having it as per the second aproach we can add arguments later if a specific 
function 
needs a specific argument.

- Original Message -
> From: "Dan Lambright" 
> To: "Hari Gowtham" 
> Cc: "Atin Mukherjee" , "gluster-users" 
> , "gluster-devel"
> 
> Sent: Saturday, October 22, 2016 10:57:21 PM
> Subject: Re: [Gluster-devel] New commands for supporting add/remove brick and 
> rebalance on tiered volume
> 
> 
> 
> - Original Message -
> > From: "Hari Gowtham" 
> > To: "Atin Mukherjee" 
> > Cc: "gluster-users" , "gluster-devel"
> > 
> > Sent: Friday, October 21, 2016 3:52:34 AM
> > Subject: Re: [Gluster-devel] New commands for supporting add/remove brick
> > and rebalance on tiered volume
> > 
> > Hi,
> > 
> > Currently there are two suggested options for the syntax of add/remove
> > brick:
> > 
> > 1) gluster v tier  add-brick [replica ] [tier-type
> > ]  ...
> > 
> > this syntax shows that its a add-brick operation on a tiered volume through
> > a
> > argument
> > instead of distinguishing using the command. The separation of tier-type is
> > done through
> > parsing. When it comes to the parsing of these [replica ] [tier-type
> > ] ,
> >  we need to parse between the tier-type, replica count and bricks. All
> >  these
> >  three variable
> >  make it complicated to parse and get the replica count, tier-type and
> >  brick.
> > 
> > currently the parsing is like:
> > w = str_getunamb (words[3], opwords_cl);
> > if (!w) {
> > type = GF_CLUSTER_TYPE_NONE;
> > .
> > .
> > } else if ((strcmp (w, "replica")) == 0) {
> > type = GF_CLUSTER_TYPE_REPLICATE;
> > .
> > .
> > }
> > } else if ((strcmp (w, "stripe")) == 0) {
> > type = GF_CLUSTER_TYPE_STRIPE;
> > .
> > .
> > } else {
> > .
> > .
> > }
> > 
> > we can use the same for replica as long as replica comes before tier-type
> > on
> > the syntax.
> > and add the parsing for tier-type using words[4] instead of words[3] and
> > repeat the same.
> > If its a plain distribute then we will be getting tier-type on words[3]. so
> > we have to parse
> > it again by checking on the wordcount. the word count influences the
> > parsing
> > to a great extent.
> > Having the tier-type after replica is looking bit off as tier-type is more
> > important here.
> > So we can have tier-type before replica count. This has to be maintained
> > thorughtout.
> > And a separate parsing can make this work. Both these will influence the
> > brick_index used
> > for parsing the brick making the switch using the word_count bit unclear.
> > This can be done but will add a lot of complications on code.
> > 
> > 2) gluster v tier  add-hot-brick/add-cold-brick [replica ]
> >  ...
> > In this syntax, we remove the tier-type from parsing and mention the type
> > on
> > the command.
> > The parsing remains the same as add-brick parsing. as differentiate between
> > the hot and cold
> > brick is done by the command
> > 
> > if (!strcmp(words[1], "detach-tier")) {
> > ret = do_cli_cmd_volume_detach_tier (state, word,
> >  words, wordcount);
> > goto out;
> > 
> > } else if (!strcmp(words[1], "attach-tier")) {
> > ret = do_cli_cmd_volume_attach_tier (state, word,
> >  words, wordcount);
> > goto out;
> > }