[Gluster-devel] Re: Gluster-devel Digest, Vol 41, Issue 13
Jake Maul
jakemaul at gmail.com
Sat Jan 10 20:49:20 UTC 2009
At my company we've stopped using reiserfs entirely, and switched to
XFS. ReiserFS 3 (the one in the kernel) doesn't seem to get a lot of
attention anymore, and Reiser4 never got into the kernel upstream
source to begin with. Compared to XFS and ext2/3/4, neither seems to
get a lot of attention.
Just my 2c....
Jake
On Fri, Jan 9, 2009 at 12:29 AM, yaomin @ gmail <yangyaomin at gmail.com> wrote:
> Ananth,
>
> Thank you for your kindness.
>
> I will try to use them as you advise. For past days, I have research the
> ReiserFS, about which some papers said it is no limitation on the number of
> the subdirectory, is it right?
>
> Thanks,
> Yaomin
> From: Ananth
> Sent: Friday, January 09, 2009 2:47 PM
> To: yaomin @ gmail
> Cc: gluster-devel at nongnu.org
> Subject: Re: [Gluster-devel] Re: Gluster-devel Digest, Vol 41, Issue 13
> Hi Yaomin,
> >From what I remember both XFS and the rather nascent EXT4 have a higher
> subdirectory limit. You could probably check ZFS as well.
> You can convert your ext3 filesystem into ext4 :
> http://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4
>
> These are just pointers as to what you can do, hence please check if the
> change in filesystem is feasible / appropriate for you, and ensure your data
> is backed up before proceeding.
>
> Regards,
> Ananth
> Z Research
>
> -----Original Message-----
> From: yaomin @ gmail <yangyaomin at gmail.com>
> To: gluster-devel at nongnu.org
> Subject: [Gluster-devel] Re: Gluster-devel Digest, Vol 41, Issue 13
> Date: Wed, 7 Jan 2009 22:54:51 +0800
>
> All,
>
> When I use the ext3 as the filesystem on the server, I have a new
> trouble that one directory at most have 31998 subdirectories. Do you have
> any advice for me?
>
> Thanks,
> Yaomin
>
> --------------------------------------------------
> From: <gluster-devel-request at nongnu.org>
> Sent: Tuesday, January 06, 2009 8:21 PM
> To: <gluster-devel at nongnu.org>
> Subject: Gluster-devel Digest, Vol 41, Issue 13
>
>> Send Gluster-devel mailing list submissions to
>> gluster-devel at nongnu.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>> or, via email, send a message with subject or body 'help' to
>> gluster-devel-request at nongnu.org
>>
>> You can reach the person managing the list at
>> gluster-devel-owner at nongnu.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Gluster-devel digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Cascading different translator doesn't work as
>> expectation (yaomin @ gmail)
>> 2. Re: Cascading different translator doesn't work as
>> expectation (Krishna Srinivas)
>> 3. Re: Cascading different translator doesn't work as
>> expectation (yaomin @ gmail)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 6 Jan 2009 17:13:49 +0800
>> From: "yaomin @ gmail" <yangyaomin at gmail.com>
>> Subject: Re: [Gluster-devel] Cascading different translator doesn't
>> work as expectation
>> To: "Krishna Srinivas" <krishna at zresearch.com>
>> Cc: gluster-devel at nongnu.org
>> Message-ID: <D7CA065B4BF644348A6DE543D8213029 at yangyaomin>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Krishna,
>>
>> Thank you for your kind help before.
>>
>> According to your advice, I confront a new error. The storage node has
>> no log information, and the client's log is like following:
>>
>> /lib64/libc.so.6[0x3fbb2300a0]
>>
>> /usr/local/lib/glusterfs/1.3.9/xlator/cluster/afr.so(afr_setxattr+0x6a)[0x2aaaaaf0658a]
>>
>> /usr/local/lib/glusterfs/1.3.9/xlator/cluster/stripe.so(notify+0x220)[0x2aaaab115c80]
>> /usr/local/lib/libglusterfs.so.0(default_notify+0x25)[0x2aaaaaab8f55]
>>
>> /usr/local/lib/glusterfs/1.3.9/xlator/cluster/afr.so(notify+0x16d)[0x2aaaaaefc19d]
>>
>> /usr/local/lib/glusterfs/1.3.9/xlator/protocol/client.so(notify+0x681)[0x2aaaaacebac1]
>> /usr/local/lib/libglusterfs.so.0(sys_epoll_iteration+0xbb)[0x2aaaaaabe14b]
>> /usr/local/lib/libglusterfs.so.0(poll_iteration+0x79)[0x2aaaaaabd509]
>> [glusterfs](main+0x66a)[0x4026aa]
>> /lib64/libc.so.6(__libc_start_main+0xf4)[0x3fbb21d8a4]
>> [glusterfs][0x401b69]
>> ---------
>>
>>
>> [root at IP6 ~]# df -h
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sda2 9.5G 6.8G 2.2G 76% /
>> /dev/sda1 190M 12M 169M 7% /boot
>> tmpfs 1006M 0 1006M 0% /dev/shm
>> /dev/sda4 447G 2.8G 422G 1% /locfs
>> /dev/sdb1 459G 199M 435G 1% /locfsb
>> df: `/mnt/new': Transport endpoint is not connected
>>
>> Thanks,
>> Yaomin
>>
>> --------------------------------------------------
>> From: "Krishna Srinivas" <krishna at zresearch.com>
>> Sent: Tuesday, January 06, 2009 1:09 PM
>> To: "yaomin @ gmail" <yangyaomin at gmail.com>
>> Cc: <gluster-devel at nongnu.org>
>> Subject: Re: [Gluster-devel] Cascading different translator doesn't work
>> as expectation
>>
>>> Alfred,
>>> Your vol files are wrong. you need to remove all the volume
>>> definitions below "writeback" in the client vol file. For server vol
>>> file the definition of performance translators is not having any
>>> effect. Also you need to use "features/locks" translator above
>>> "storage/posix"
>>> Krishna
>>>
>>> On Tue, Jan 6, 2009 at 8:51 AM, yaomin @ gmail <yangyaomin at gmail.com>
>>> wrote:
>>>> All,
>>>>
>>>> It seems difficult for you.
>>>>
>>>> There is a new problem when I tested.
>>>>
>>>> When I kill all the storage nodes, the client still try to send
>>>> data,
>>>> and doesn't quit.
>>>>
>>>> Thanks,
>>>> Alfred
>>>> From: yaomin @ gmail
>>>> Sent: Monday, January 05, 2009 10:52 PM
>>>> To: Krishna Srinivas
>>>> Cc: gluster-devel at nongnu.org
>>>> Subject: Re: [Gluster-devel] Cascading different translator doesn't work
>>>> as
>>>> expectation
>>>> Krishna,
>>>> Thank you for your quick response.
>>>> There are two log information in the client's log file when setting
>>>> up
>>>> the client.
>>>> 2009-01-05 18:44:59 W [fuse-bridge.c:389:fuse_entry_cbk]
>>>> glusterfs-fuse:
>>>> 2: (34) / => 1 Rehashing 0/0
>>>> 2009-01-05 18:48:04 W [fuse-bridge.c:389:fuse_entry_cbk]
>>>> glusterfs-fuse:
>>>> 2: (34) / => 1 Rehashing 0/0
>>>>
>>>> There is no any information in the storage node's log file.
>>>>
>>>> Although I changed the scheduler from ALU to RR, there only the
>>>> No.3(192.168.13.5) and No.4(192.168.13.7) storage nodes on working.
>>>>
>>>> Each machine has 2GB memory.
>>>>
>>>> Thanks,
>>>> Alfred
>>>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>>
>> http://lists.gnu.org/pipermail/gluster-devel/attachments/20090106/76074e85/attachment.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 6 Jan 2009 15:06:42 +0530
>> From: "Krishna Srinivas" <krishna at zresearch.com>
>> Subject: Re: [Gluster-devel] Cascading different translator doesn't
>> work as expectation
>> To: "yaomin @ gmail" <yangyaomin at gmail.com>
>> Cc: gluster-devel at nongnu.org
>> Message-ID:
>> <ad4bc5820901060136k2a3c0943nd89b0d4f41240e22 at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Yaomin,
>>
>> Can you:
>> * mention what version you are using
>> * give the modified client and server vol file (to see if there are any
>> errors)
>> * give gdb backtrace from the core file? "gdb -c /core.pid glusterfs"
>> and then type "bt"
>>
>> Krishna
>>
>> On Tue, Jan 6, 2009 at 2:43 PM, yaomin @ gmail <yangyaomin at gmail.com>
>> wrote:
>>> Krishna,
>>>
>>> Thank you for your kind help before.
>>>
>>> According to your advice, I confront a new error. The storage node
>>> has
>>> no log information, and the client's log is like following:
>>>
>>> /lib64/libc.so.6[0x3fbb2300a0]
>>>
>>> /usr/local/lib/glusterfs/1.3.9/xlator/cluster/afr.so(afr_setxattr+0x6a)[0x2aaaaaf0658a]
>>>
>>> /usr/local/lib/glusterfs/1.3.9/xlator/cluster/stripe.so(notify+0x220)[0x2aaaab115c80]
>>> /usr/local/lib/libglusterfs.so.0(default_notify+0x25)[0x2aaaaaab8f55]
>>>
>>> /usr/local/lib/glusterfs/1.3.9/xlator/cluster/afr.so(notify+0x16d)[0x2aaaaaefc19d]
>>>
>>> /usr/local/lib/glusterfs/1.3.9/xlator/protocol/client.so(notify+0x681)[0x2aaaaacebac1]
>>>
>>> /usr/local/lib/libglusterfs.so.0(sys_epoll_iteration+0xbb)[0x2aaaaaabe14b]
>>> /usr/local/lib/libglusterfs.so.0(poll_iteration+0x79)[0x2aaaaaabd509]
>>> [glusterfs](main+0x66a)[0x4026aa]
>>> /lib64/libc.so.6(__libc_start_main+0xf4)[0x3fbb21d8a4]
>>> [glusterfs][0x401b69]
>>> ---------
>>>
>>> [root at IP6 ~]# df -h
>>> Filesystem Size Used Avail Use% Mounted on
>>> /dev/sda2 9.5G 6.8G 2.2G 76% /
>>> /dev/sda1 190M 12M 169M 7% /boot
>>> tmpfs 1006M 0 1006M 0% /dev/shm
>>> /dev/sda4 447G 2.8G 422G 1% /locfs
>>> /dev/sdb1 459G 199M 435G 1% /locfsb
>>> df: `/mnt/new': Transport endpoint is not connected
>>>
>>> Thanks,
>>> Yaomin
>>> --------------------------------------------------
>>> From: "Krishna Srinivas" <krishna at zresearch.com>
>>> Sent: Tuesday, January 06, 2009 1:09 PM
>>> To: "yaomin @ gmail" <yangyaomin at gmail.com>
>>> Cc: <gluster-devel at nongnu.org>
>>> Subject: Re: [Gluster-devel] Cascading different translator doesn't work
>>> as
>>> expectation
>>>
>>>> Alfred,
>>>> Your vol files are wrong. you need to remove all the volume
>>>> definitions below "writeback" in the client vol file. For server vol
>>>> file the definition of performance translators is not having any
>>>> effect. Also you need to use "features/locks" translator above
>>>> "storage/posix"
>>>> Krishna
>>>>
>>>> On Tue, Jan 6, 2009 at 8:51 AM, yaomin @ gmail <yangyaomin at gmail.com>
>>>> wrote:
>>>>> All,
>>>>>
>>>>> It seems difficult for you.
>>>>>
>>>>> There is a new problem when I tested.
>>>>>
>>>>> When I kill all the storage nodes, the client still try to send
>>>>> data,
>>>>> and doesn't quit.
>>>>>
>>>>> Thanks,
>>>>> Alfred
>>>>> From: yaomin @ gmail
>>>>> Sent: Monday, January 05, 2009 10:52 PM
>>>>> To: Krishna Srinivas
>>>>> Cc: gluster-devel at nongnu.org
>>>>> Subject: Re: [Gluster-devel] Cascading different translator doesn't
>>>>> work
>>>>> as
>>>>> expectation
>>>>> Krishna,
>>>>> Thank you for your quick response.
>>>>> There are two log information in the client's log file when setting
>>>>> up
>>>>> the client.
>>>>> 2009-01-05 18:44:59 W [fuse-bridge.c:389:fuse_entry_cbk]
>>>>> glusterfs-fuse:
>>>>> 2: (34) / => 1 Rehashing 0/0
>>>>> 2009-01-05 18:48:04 W [fuse-bridge.c:389:fuse_entry_cbk]
>>>>> glusterfs-fuse:
>>>>> 2: (34) / => 1 Rehashing 0/0
>>>>>
>>>>> There is no any information in the storage node's log file.
>>>>>
>>>>> Although I changed the scheduler from ALU to RR, there only the
>>>>> No.3(192.168.13.5) and No.4(192.168.13.7) storage nodes on working.
>>>>>
>>>>> Each machine has 2GB memory.
>>>>>
>>>>> Thanks,
>>>>> Alfred
>>>>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 6 Jan 2009 20:21:35 +0800
>> From: "yaomin @ gmail" <yangyaomin at gmail.com>
>> Subject: Re: [Gluster-devel] Cascading different translator doesn't
>> work as expectation
>> To: "Krishna Srinivas" <krishna at zresearch.com>
>> Cc: gluster-devel at nongnu.org
>> Message-ID: <CA759DEFFF2C42AA877946E88BD53E42 at yangyaomin>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Krishna,
>>
>> 1, The version is 1.3.9
>> 2, the client and server vol files are in the attachments.
>> 3, The result is "No Stack"
>>
>> Thanks,
>> Yaomin
>>
>> --------------------------------------------------
>> From: "Krishna Srinivas" <krishna at zresearch.com>
>> Sent: Tuesday, January 06, 2009 5:36 PM
>> To: "yaomin @ gmail" <yangyaomin at gmail.com>
>> Cc: <gluster-devel at nongnu.org>
>> Subject: Re: [Gluster-devel] Cascading different translator doesn't work
>> as
>> expectation
>>
>>> Yaomin,
>>>
>>> Can you:
>>> * mention what version you are using
>>> * give the modified client and server vol file (to see if there are any
>>> errors)
>>> * give gdb backtrace from the core file? "gdb -c /core.pid glusterfs"
>>> and then type "bt"
>>>
>>> Krishna
>>>
>>> On Tue, Jan 6, 2009 at 2:43 PM, yaomin @ gmail <yangyaomin at gmail.com>
>>> wrote:
>>>> Krishna,
>>>>
>>>> Thank you for your kind help before.
>>>>
>>>> According to your advice, I confront a new error. The storage node
>>>> has
>>>> no log information, and the client's log is like following:
>>>>
>>>> /lib64/libc.so.6[0x3fbb2300a0]
>>>>
>>>> /usr/local/lib/glusterfs/1.3.9/xlator/cluster/afr.so(afr_setxattr+0x6a)[0x2aaaaaf0658a]
>>>>
>>>> /usr/local/lib/glusterfs/1.3.9/xlator/cluster/stripe.so(notify+0x220)[0x2aaaab115c80]
>>>> /usr/local/lib/libglusterfs.so.0(default_notify+0x25)[0x2aaaaaab8f55]
>>>>
>>>> /usr/local/lib/glusterfs/1.3.9/xlator/cluster/afr.so(notify+0x16d)[0x2aaaaaefc19d]
>>>>
>>>> /usr/local/lib/glusterfs/1.3.9/xlator/protocol/client.so(notify+0x681)[0x2aaaaacebac1]
>>>>
>>>> /usr/local/lib/libglusterfs.so.0(sys_epoll_iteration+0xbb)[0x2aaaaaabe14b]
>>>> /usr/local/lib/libglusterfs.so.0(poll_iteration+0x79)[0x2aaaaaabd509]
>>>> [glusterfs](main+0x66a)[0x4026aa]
>>>> /lib64/libc.so.6(__libc_start_main+0xf4)[0x3fbb21d8a4]
>>>> [glusterfs][0x401b69]
>>>> ---------
>>>>
>>>> [root at IP6 ~]# df -h
>>>> Filesystem Size Used Avail Use% Mounted on
>>>> /dev/sda2 9.5G 6.8G 2.2G 76% /
>>>> /dev/sda1 190M 12M 169M 7% /boot
>>>> tmpfs 1006M 0 1006M 0% /dev/shm
>>>> /dev/sda4 447G 2.8G 422G 1% /locfs
>>>> /dev/sdb1 459G 199M 435G 1% /locfsb
>>>> df: `/mnt/new': Transport endpoint is not connected
>>>>
>>>> Thanks,
>>>> Yaomin
>>>> --------------------------------------------------
>>>> From: "Krishna Srinivas" <krishna at zresearch.com>
>>>> Sent: Tuesday, January 06, 2009 1:09 PM
>>>> To: "yaomin @ gmail" <yangyaomin at gmail.com>
>>>> Cc: <gluster-devel at nongnu.org>
>>>> Subject: Re: [Gluster-devel] Cascading different translator doesn't work
>>>> as
>>>> expectation
>>>>
>>>>> Alfred,
>>>>> Your vol files are wrong. you need to remove all the volume
>>>>> definitions below "writeback" in the client vol file. For server vol
>>>>> file the definition of performance translators is not having any
>>>>> effect. Also you need to use "features/locks" translator above
>>>>> "storage/posix"
>>>>> Krishna
>>>>>
>>>>> On Tue, Jan 6, 2009 at 8:51 AM, yaomin @ gmail <yangyaomin at gmail.com>
>>>>> wrote:
>>>>>> All,
>>>>>>
>>>>>> It seems difficult for you.
>>>>>>
>>>>>> There is a new problem when I tested.
>>>>>>
>>>>>> When I kill all the storage nodes, the client still try to send
>>>>>> data,
>>>>>> and doesn't quit.
>>>>>>
>>>>>> Thanks,
>>>>>> Alfred
>>>>>> From: yaomin @ gmail
>>>>>> Sent: Monday, January 05, 2009 10:52 PM
>>>>>> To: Krishna Srinivas
>>>>>> Cc: gluster-devel at nongnu.org
>>>>>> Subject: Re: [Gluster-devel] Cascading different translator doesn't
>>>>>> work
>>>>>> as
>>>>>> expectation
>>>>>> Krishna,
>>>>>> Thank you for your quick response.
>>>>>> There are two log information in the client's log file when
>>>>>> setting
>>>>>> up
>>>>>> the client.
>>>>>> 2009-01-05 18:44:59 W [fuse-bridge.c:389:fuse_entry_cbk]
>>>>>> glusterfs-fuse:
>>>>>> 2: (34) / => 1 Rehashing 0/0
>>>>>> 2009-01-05 18:48:04 W [fuse-bridge.c:389:fuse_entry_cbk]
>>>>>> glusterfs-fuse:
>>>>>> 2: (34) / => 1 Rehashing 0/0
>>>>>>
>>>>>> There is no any information in the storage node's log file.
>>>>>>
>>>>>> Although I changed the scheduler from ALU to RR, there only the
>>>>>> No.3(192.168.13.5) and No.4(192.168.13.7) storage nodes on working.
>>>>>>
>>>>>> Each machine has 2GB memory.
>>>>>>
>>>>>> Thanks,
>>>>>> Alfred
>>>>>>
>> -------------- next part --------------
>> volume client-ns
>> type protocol/client
>> option transport-type tcp/client # for TCP/IP transport
>> option remote-host 192.168.13.2 # IP address of the remote brick
>> # option remote-port 6996 # default server port is 6996
>> # option transport-timeout 30 # seconds to wait for a response
>> # from server for each request
>> option remote-subvolume name_space # name of the remote volume
>> end-volume
>>
>> volume client11
>> type protocol/client
>> option transport-type tcp/client # for TCP/IP transport
>> option remote-host 192.168.13.2 # IP address of the remote brick
>> # option remote-port 6996 # default server port is 6996
>> # option transport-timeout 30 # seconds to wait for a response
>> # from server for each request
>> option remote-subvolume brick1 # name of the remote volume
>> end-volume
>>
>> volume client12
>> type protocol/client
>> option transport-type tcp/client # for TCP/IP transport
>> option remote-host 192.168.13.2 # IP address of the remote brick
>> # option remote-port 6996 # default server port is 6996
>> # option transport-timeout 30 # seconds to wait for a response
>> # from server for each request
>> option remote-subvolume brick2 # name of the remote volume
>> end-volume
>>
>>
>> volume client21
>> type protocol/client
>> option transport-type tcp/client # for TCP/IP transport
>> option remote-host 192.168.13.4 # IP address of the remote brick
>> # option remote-port 6996 # default server port is 6996
>> # option transport-timeout 30 # seconds to wait for a response
>> # from server for each request
>> option remote-subvolume brick1 # name of the remote volume
>> end-volume
>>
>> volume client22
>> type protocol/client
>> option transport-type tcp/client # for TCP/IP transport
>> option remote-host 192.168.13.4 # IP address of the remote brick
>> # option remote-port 6996 # default server port is 6996
>> # option transport-timeout 30 # seconds to wait for a response
>> # from server for each request
>> option remote-subvolume brick2 # name of the remote volume
>> end-volume
>>
>> volume client31
>> type protocol/client
>> option transport-type tcp/client # for TCP/IP transport
>> option remote-host 192.168.13.5 # IP address of the remote brick
>> # option remote-port 6996 # default server port is 6996
>> # option transport-timeout 30 # seconds to wait for a response
>> # from server for each request
>> option remote-subvolume brick1 # name of the remote volume
>> end-volume
>>
>> volume client32
>> type protocol/client
>> option transport-type tcp/client # for TCP/IP transport
>> option remote-host 192.168.13.5 # IP address of the remote brick
>> # option remote-port 6996 # default server port is 6996
>> # option transport-timeout 30 # seconds to wait for a response
>> # from server for each request
>> option remote-subvolume brick2 # name of the remote volume
>> end-volume
>>
>> volume client41
>> type protocol/client
>> option transport-type tcp/client # for TCP/IP transport
>> option remote-host 192.168.13.7 # IP address of the remote brick
>> # option remote-port 6996 # default server port is 6996
>> # option transport-timeout 30 # seconds to wait for a response
>> # from server for each request
>> option remote-subvolume brick1 # name of the remote volume
>> end-volume
>>
>> volume client42
>> type protocol/client
>> option transport-type tcp/client # for TCP/IP transport
>> option remote-host 192.168.13.7 # IP address of the remote brick
>> # option remote-port 6996 # default server port is 6996
>> # option transport-timeout 30 # seconds to wait for a response
>> # from server for each request
>> option remote-subvolume brick2 # name of the remote volume
>> end-volume
>>
>> volume afr1
>> type cluster/afr
>> subvolumes client11 client21
>> option debug off # turns on detailed debug messages
>> # in log by default is debugging off
>> option self-heal on # turn off self healing default is on
>> end-volume
>>
>> volume afr2
>> type cluster/afr
>> subvolumes client31 client41
>> option debug off # turns on detailed debug messages
>> # in log by default is debugging off
>> option self-heal on # turn off self healing default is on
>> end-volume
>>
>> volume afr3
>> type cluster/afr
>> subvolumes client12 client22
>> option debug off # turns on detailed debug messages
>> # in log by default is debugging off
>> option self-heal on # turn off self healing default is on
>> end-volume
>>
>> volume afr4
>> type cluster/afr
>> subvolumes client32 client42
>> option debug off # turns on detailed debug messages
>> # in log by default is debugging off
>> option self-heal on # turn off self healing default is on
>> end-volume
>>
>> volume stripe1
>> type cluster/stripe
>> option block-size 1MB #default size is 128KB
>> subvolumes afr1 afr2
>> end-volume
>>
>> volume stripe2
>> type cluster/stripe
>> option block-size 1MB #default size is 128KB
>> subvolumes afr3 afr4
>> end-volume
>>
>>
>>
>> volume bricks
>> type cluster/unify
>> subvolumes stripe1 stripe2
>> option namespace client-ns
>> option scheduler rr
>> end-volume
>>
>>
>> ### Add io-threads feature
>> volume iot
>> type performance/io-threads
>> option thread-count 1 # deault is 1
>> option cache-size 16MB #64MB
>>
>> subvolumes bricks #stripe #afr #bricks
>> end-volume
>>
>> ### Add readahead feature
>> volume readahead
>> type performance/read-ahead
>> option page-size 1MB # unit in bytes
>> option page-count 4 # cache per file = (page-count x page-size)
>> subvolumes iot
>> end-volume
>>
>> ### Add IO-Cache feature
>> volume iocache
>> type performance/io-cache
>> option page-size 256KB
>> option page-count 8
>> subvolumes readahead
>> end-volume
>>
>> ### Add writeback feature
>> volume writeback
>> type performance/write-behind
>> option aggregate-size 1MB #option flush-behind off
>> option window-size 3MB # default is 0bytes
>> # option flush-behind on # default is 'off'
>> subvolumes iocache
>> end-volume
>> -------------- next part --------------
>> volume name_space
>> type storage/posix
>> option directory /locfsb/name_space
>> end-volume
>>
>> volume brick_1
>> type storage/posix # POSIX FS translator
>> option directory /locfs/brick # Export this directory
>> end-volume
>>
>>
>> volume brick1
>> type features/posix-locks # POSIX FS translator
>> subvolumes brick_1
>> end-volume
>>
>> volume brick_2
>> type storage/posix # POSIX FS translator
>> option directory /locfsb/brick # Export this directory
>> end-volume
>>
>>
>> volume brick2
>> type features/posix-locks # POSIX FS translator
>> subvolumes brick_2
>> end-volume
>>
>> volume server
>> type protocol/server
>> option transport-type tcp/server # For TCP/IP transport
>> # option listen-port 6996 # Default is 6996
>> # option client-volume-filename /etc/glusterfs/glusterfs-client.vol
>> subvolumes brick1 brick2 name_space
>> option auth.ip.brick1.allow 192.168.13.* # Allow access to "brick1"
>> volume
>> option auth.ip.brick2.allow 192.168.13.* # Allow access to "brick2"
>> volume
>> option auth.ip.name_space.allow 192.168.13.* # Allow access to
>> "name_space" volume
>> end-volume
>>
>> ------------------------------
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>>
>> End of Gluster-devel Digest, Vol 41, Issue 13
>> *********************************************
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
More information about the Gluster-devel
mailing list