Re: [sheepdog] Issues about setup
At Tue, 20 Jan 2015 10:46:38 +0800, hujianyang wrote: On 2015/1/20 10:32, Hitoshi Mitake wrote: I did a little change and it compiles OK. But UINT*_C are widely used in sheepdog_proto.h so maybe a large-scale modification is needed? Cc-ing Alexander. The above UINT*_C macro problem is solved by the recent patch of Alexander. But the kstrtoul() problem still remains. If you can create a patch for it, I'll apply it. Also, kernel modules should be changed besides different kernel versions. How about separating kernel module code from userspace sheepdog package? The main interfaces for modules provided by linux kernel seem to be (almost) stable. If we can avoid to use (few) unstable interface, separating it from our repository isn't required, I think. Agree! By the way, there are too many log messages while using sheepdog device. Can we stop its printing? I don't have time to maintain sbd. If you can post a patch for reducing message, I'll apply. Yes, I'll do this. Sorry, our converstation is interleaving... I created and posted a patch for it. But feel free to post your patch. If you want to join development of sheepdog, it will be a good practice :) I'll discard my patch. Thanks, Hitoshi -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] Issues about setup
At Mon, 19 Jan 2015 16:29:17 +0800,
hujianyang wrote:
Hi Hitoshi,
On 2015/1/16 17:40, Hitoshi Mitake wrote:
Hmm, could you show your yasm version? My yasm (1.2.0) can build
current master branch with no problems.
Thanks,
Hitoshi
Thanks for your advise. I've updated my yasm to 1.3.0 and found it's
OK. I think maybe we should mark this requirement also in configure
file.
Now I'm trying to use sheepdog backing device. Errors occur while
compiling sbd kernel module:
linux-2hp8:/opt/sheepdog/sbd # make
make -C /lib/modules/`uname -r`/build M=$PWD modules
make[1]: Entering directory `/opt/linux-3.18.2'
CC [M] /opt/sheepdog/sbd/sheep_block_device.o
In file included from /opt/sheepdog/sbd/sbd.h:20,
from /opt/sheepdog/sbd/sheep_block_device.c:48:
/opt/sheepdog/sbd/../include/sheepdog_proto.h: In function ‘count_data_objs’:
/opt/sheepdog/sbd/../include/sheepdog_proto.h:495: error: implicit
declaration of function ‘UINT32_C’
/opt/sheepdog/sbd/sheep_block_device.c: In function ‘sbd_remove’:
/opt/sheepdog/sbd/sheep_block_device.c:293: error: implicit declaration of
function ‘strict_strtoul’
make[2]: *** [/opt/sheepdog/sbd/sheep_block_device.o] Error 1
make[1]: *** [_module_/opt/sheepdog/sbd] Error 2
make[1]: Leaving directory `/opt/linux-3.18.2'
make: *** [default] Error 2
My kernel version is 3.18.2. Seems UINT32_C is not used in kernel
and strict_strtoul has been replaced by kstrtoul in my kernel.
diff --git a/include/sheepdog_proto.h b/include/sheepdog_proto.h
index 3910bd5..0599ece 100644
--- a/include/sheepdog_proto.h
+++ b/include/sheepdog_proto.h
@@ -493,7 +493,7 @@ static inline bool is_data_obj(uint64_t oid)
static inline size_t count_data_objs(const struct sd_inode *inode)
{
return DIV_ROUND_UP(inode-vdi_size,
- (UINT32_C(1) inode-block_size_shift));
+ (1UL inode-block_size_shift));
}
static inline size_t get_objsize(uint64_t oid, uint32_t object_size)
diff --git a/sbd/sheep_block_device.c b/sbd/sheep_block_device.c
index eaee932..d82ff43 100644
--- a/sbd/sheep_block_device.c
+++ b/sbd/sheep_block_device.c
@@ -290,7 +290,7 @@ static ssize_t sbd_remove(struct bus_type *bus, const
char *buf,
unsigned long ul;
int target_id, ret;
- ret = strict_strtoul(buf, 10, ul);
+ ret = kstrtoul(buf, 10, ul);
if (ret)
return ret;
I did a little change and it compiles OK. But UINT*_C are widely
used in sheepdog_proto.h so maybe a large-scale modification is
needed?
Cc-ing Alexander. The above UINT*_C macro problem is solved by the
recent patch of Alexander. But the kstrtoul() problem still
remains. If you can create a patch for it, I'll apply it.
Also, kernel modules should be changed besides different kernel
versions. How about separating kernel module code from userspace
sheepdog package?
The main interfaces for modules provided by linux kernel seem to be
(almost) stable. If we can avoid to use (few) unstable interface,
separating it from our repository isn't required, I think.
Another interesting thing, A sbd device cannot be re-add after
removing it.
Fs-Server:/opt/GIT/sheepdog/sbd # echo 130.1.0.147 7000 Hu0 /sys/bus/sbd/add
Fs-Server:/opt/GIT/sheepdog/sbd # cat /sys/bus/sbd/list
0 Hu0
Fs-Server:/opt/GIT/sheepdog/sbd # echo 0 /sys/bus/sbd/remove
Fs-Server:/opt/GIT/sheepdog/sbd # echo 130.1.0.147 7000 Hu0 /sys/bus/sbd/add
-bash: echo: write error: Input/output error
Jan 19 15:52:35 Fs-Server kernel: [364284.639557] sbd: Associated to Hu0
Jan 19 15:52:35 Fs-Server kernel: [364284.640389] sbd:sheep_aiocb_submit:516:
submit off 0, len 4096
Jan 19 15:52:35 Fs-Server kernel: [364284.640397] sbd:end_sheep_request:469:
end oid 6e7762 off 0, len 4096, seq 1
Jan 19 15:52:35 Fs-Server kernel: [364284.640400] sbd:aio_read_done:360:
rdone off 0, len 4096
Jan 19 15:52:35 Fs-Server kernel: [364284.640444] sbd:sheep_aiocb_submit:516:
submit off 12288, len 4096
Jan 19 15:52:35 Fs-Server kernel: [364284.640448] sbd:end_sheep_request:469:
end oid 6e7762 off 12288, len 4096, seq 2
Jan 19 15:52:35 Fs-Server kernel: [364284.640451] sbd:aio_read_done:360:
rdone off 12288, len 4096
Jan 19 15:52:35 Fs-Server kernel: [364284.640465] sbd0: unknown partition
table
Jan 19 15:53:18 Fs-Server kernel: [364328.123575] Cannot get VDI for Hu0, -5
Jan 19 15:53:18 Fs-Server kernel: [364328.124265] sbd: error adding device
130.1.0.147 7000 Hu0
If you have no idea about this problem, I'd like to take some
time look at it.
By the way, there are too many log messages while using sheepdog
device. Can we stop its printing?
I don't have time to maintain sbd. If you can post a patch for
reducing message, I'll apply.
BTW, what is the purpose of using sbd? AFAIK, it cannot handle a fault
of sheep process which is connected to sbd. If you want to use
sheepdog
Re: [sheepdog] Issues about setup
On 2015/1/20 10:32, Hitoshi Mitake wrote: I did a little change and it compiles OK. But UINT*_C are widely used in sheepdog_proto.h so maybe a large-scale modification is needed? Cc-ing Alexander. The above UINT*_C macro problem is solved by the recent patch of Alexander. But the kstrtoul() problem still remains. If you can create a patch for it, I'll apply it. Also, kernel modules should be changed besides different kernel versions. How about separating kernel module code from userspace sheepdog package? The main interfaces for modules provided by linux kernel seem to be (almost) stable. If we can avoid to use (few) unstable interface, separating it from our repository isn't required, I think. Agree! By the way, there are too many log messages while using sheepdog device. Can we stop its printing? I don't have time to maintain sbd. If you can post a patch for reducing message, I'll apply. Yes, I'll do this. BTW, what is the purpose of using sbd? AFAIK, it cannot handle a fault of sheep process which is connected to sbd. If you want to use sheepdog as an alternative of SAN, I'd like to suggest iSCSI interface. Below is an instruction: https://github.com/sheepdog/sheepdog/wiki/General-protocol-support-%28iSCSI-and-NBD%29#iscsi Thanks~! I'll look at it. -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] Issues about setup
On 2015/1/20 10:49, Hitoshi Mitake wrote: At Tue, 20 Jan 2015 10:46:38 +0800, hujianyang wrote: On 2015/1/20 10:32, Hitoshi Mitake wrote: I did a little change and it compiles OK. But UINT*_C are widely used in sheepdog_proto.h so maybe a large-scale modification is needed? Cc-ing Alexander. The above UINT*_C macro problem is solved by the recent patch of Alexander. But the kstrtoul() problem still remains. If you can create a patch for it, I'll apply it. Also, kernel modules should be changed besides different kernel versions. How about separating kernel module code from userspace sheepdog package? The main interfaces for modules provided by linux kernel seem to be (almost) stable. If we can avoid to use (few) unstable interface, separating it from our repository isn't required, I think. Agree! By the way, there are too many log messages while using sheepdog device. Can we stop its printing? I don't have time to maintain sbd. If you can post a patch for reducing message, I'll apply. Yes, I'll do this. Sorry, our converstation is interleaving... I created and posted a patch for it. But feel free to post your patch. If you want to join development of sheepdog, it will be a good practice :) I'll discard my patch. Oh, Never mind~! I think I'll working on sheepdog for a long time. There must be lots of opportunities. I'm not a person who just ask but do not contribute. Thanks your great help again~! Hu -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] Issues about setup
At Tue, 20 Jan 2015 11:00:53 +0800, hujianyang wrote: On 2015/1/20 10:49, Hitoshi Mitake wrote: At Tue, 20 Jan 2015 10:46:38 +0800, hujianyang wrote: On 2015/1/20 10:32, Hitoshi Mitake wrote: I did a little change and it compiles OK. But UINT*_C are widely used in sheepdog_proto.h so maybe a large-scale modification is needed? Cc-ing Alexander. The above UINT*_C macro problem is solved by the recent patch of Alexander. But the kstrtoul() problem still remains. If you can create a patch for it, I'll apply it. Also, kernel modules should be changed besides different kernel versions. How about separating kernel module code from userspace sheepdog package? The main interfaces for modules provided by linux kernel seem to be (almost) stable. If we can avoid to use (few) unstable interface, separating it from our repository isn't required, I think. Agree! By the way, there are too many log messages while using sheepdog device. Can we stop its printing? I don't have time to maintain sbd. If you can post a patch for reducing message, I'll apply. Yes, I'll do this. Sorry, our converstation is interleaving... I created and posted a patch for it. But feel free to post your patch. If you want to join development of sheepdog, it will be a good practice :) I'll discard my patch. Oh, Never mind~! I think I'll working on sheepdog for a long time. There must be lots of opportunities. I'm really glad to hear that :) I'm not a person who just ask but do not contribute. I know some of your contribution for linux kernel, e.g. UBIFS. You seem to be really experienced developer :) If you can help us, it is really great. Thanks, Hitoshi Thanks your great help again~! Hu -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] Issues about setup
Hi Hitoshi,
On 2015/1/16 17:40, Hitoshi Mitake wrote:
Hmm, could you show your yasm version? My yasm (1.2.0) can build
current master branch with no problems.
Thanks,
Hitoshi
Thanks for your advise. I've updated my yasm to 1.3.0 and found it's
OK. I think maybe we should mark this requirement also in configure
file.
Now I'm trying to use sheepdog backing device. Errors occur while
compiling sbd kernel module:
linux-2hp8:/opt/sheepdog/sbd # make
make -C /lib/modules/`uname -r`/build M=$PWD modules
make[1]: Entering directory `/opt/linux-3.18.2'
CC [M] /opt/sheepdog/sbd/sheep_block_device.o
In file included from /opt/sheepdog/sbd/sbd.h:20,
from /opt/sheepdog/sbd/sheep_block_device.c:48:
/opt/sheepdog/sbd/../include/sheepdog_proto.h: In function ‘count_data_objs’:
/opt/sheepdog/sbd/../include/sheepdog_proto.h:495: error: implicit declaration
of function ‘UINT32_C’
/opt/sheepdog/sbd/sheep_block_device.c: In function ‘sbd_remove’:
/opt/sheepdog/sbd/sheep_block_device.c:293: error: implicit declaration of
function ‘strict_strtoul’
make[2]: *** [/opt/sheepdog/sbd/sheep_block_device.o] Error 1
make[1]: *** [_module_/opt/sheepdog/sbd] Error 2
make[1]: Leaving directory `/opt/linux-3.18.2'
make: *** [default] Error 2
My kernel version is 3.18.2. Seems UINT32_C is not used in kernel
and strict_strtoul has been replaced by kstrtoul in my kernel.
diff --git a/include/sheepdog_proto.h b/include/sheepdog_proto.h
index 3910bd5..0599ece 100644
--- a/include/sheepdog_proto.h
+++ b/include/sheepdog_proto.h
@@ -493,7 +493,7 @@ static inline bool is_data_obj(uint64_t oid)
static inline size_t count_data_objs(const struct sd_inode *inode)
{
return DIV_ROUND_UP(inode-vdi_size,
- (UINT32_C(1) inode-block_size_shift));
+ (1UL inode-block_size_shift));
}
static inline size_t get_objsize(uint64_t oid, uint32_t object_size)
diff --git a/sbd/sheep_block_device.c b/sbd/sheep_block_device.c
index eaee932..d82ff43 100644
--- a/sbd/sheep_block_device.c
+++ b/sbd/sheep_block_device.c
@@ -290,7 +290,7 @@ static ssize_t sbd_remove(struct bus_type *bus, const char
*buf,
unsigned long ul;
int target_id, ret;
- ret = strict_strtoul(buf, 10, ul);
+ ret = kstrtoul(buf, 10, ul);
if (ret)
return ret;
I did a little change and it compiles OK. But UINT*_C are widely
used in sheepdog_proto.h so maybe a large-scale modification is
needed?
Also, kernel modules should be changed besides different kernel
versions. How about separating kernel module code from userspace
sheepdog package?
Another interesting thing, A sbd device cannot be re-add after
removing it.
Fs-Server:/opt/GIT/sheepdog/sbd # echo 130.1.0.147 7000 Hu0 /sys/bus/sbd/add
Fs-Server:/opt/GIT/sheepdog/sbd # cat /sys/bus/sbd/list
0 Hu0
Fs-Server:/opt/GIT/sheepdog/sbd # echo 0 /sys/bus/sbd/remove
Fs-Server:/opt/GIT/sheepdog/sbd # echo 130.1.0.147 7000 Hu0 /sys/bus/sbd/add
-bash: echo: write error: Input/output error
Jan 19 15:52:35 Fs-Server kernel: [364284.639557] sbd: Associated to Hu0
Jan 19 15:52:35 Fs-Server kernel: [364284.640389] sbd:sheep_aiocb_submit:516:
submit off 0, len 4096
Jan 19 15:52:35 Fs-Server kernel: [364284.640397] sbd:end_sheep_request:469:
end oid 6e7762 off 0, len 4096, seq 1
Jan 19 15:52:35 Fs-Server kernel: [364284.640400] sbd:aio_read_done:360: rdone
off 0, len 4096
Jan 19 15:52:35 Fs-Server kernel: [364284.640444] sbd:sheep_aiocb_submit:516:
submit off 12288, len 4096
Jan 19 15:52:35 Fs-Server kernel: [364284.640448] sbd:end_sheep_request:469:
end oid 6e7762 off 12288, len 4096, seq 2
Jan 19 15:52:35 Fs-Server kernel: [364284.640451] sbd:aio_read_done:360: rdone
off 12288, len 4096
Jan 19 15:52:35 Fs-Server kernel: [364284.640465] sbd0: unknown partition table
Jan 19 15:53:18 Fs-Server kernel: [364328.123575] Cannot get VDI for Hu0, -5
Jan 19 15:53:18 Fs-Server kernel: [364328.124265] sbd: error adding device
130.1.0.147 7000 Hu0
If you have no idea about this problem, I'd like to take some
time look at it.
By the way, there are too many log messages while using sheepdog
device. Can we stop its printing?
One important thing, seems yasm are not used in v8.3.0 and are
required since v9.0 because of erasure_code? Where can I get
more information about erasure_code in sheepdog except of the
wiki page in github?
Please forgive me for lots of questions.
Thanks,
Hu
--
sheepdog mailing list
sheepdog@lists.wpkg.org
https://lists.wpkg.org/mailman/listinfo/sheepdog
[sheepdog] Issues about setup
Hi Hitoshi, I'm a learner of sheepdog. Here is two issues about setting up sheepdog in my environment. 1) invalid option '-d' in README To set up a 3 node cluster using local driver in one liner bash with debug mode: $ mkdir /path/to/store $ for i in 0 1 2; do sheep -c local -d /path/to/store/$i -z $i -p 700$i;sleep 1;done but: $ sheep -c local -d /mnt/store/0 -z 0 -p 7000 sheep: invalid option -- 'd' Try 'sheep --help' for more information. Seems '-d' is removed so maybe README file should be updated? 2) compile error in version v0.9.0+ When compile sheepdog v0.9.0+, I met a lots of error messages below: yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_mul_sse.o erasure_code/gf_vect_mul_sse.asm --- Building erasure_code/gf_vect_mul_avx.asm yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_mul_avx.o erasure_code/gf_vect_mul_avx.asm --- Building erasure_code/gf_vect_dot_prod_sse.asm yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_dot_prod_sse.o erasure_code/gf_vect_dot_prod_sse.asm erasure_code/gf_vect_mul_avx.asm:116: instruction expected after label erasure_code/gf_vect_mul_avx.asm:117: instruction expected after label erasure_code/gf_vect_mul_avx.asm:118: redefinition of `vmovdqu' erasure_code/gf_vect_mul_avx.asm:117: `vmovdqu' previously defined here erasure_code/gf_vect_mul_avx.asm:121: instruction expected after label erasure_code/gf_vect_mul_avx.asm:122: redefinition of `vmovntdqa' erasure_code/gf_vect_mul_avx.asm:121: `vmovntdqa' previously defined here erasure_code/gf_vect_mul_avx.asm:125: instruction expected after label erasure_code/gf_vect_mul_avx.asm:126: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:127: instruction expected after label erasure_code/gf_vect_mul_avx.asm:128: redefinition of `vpsraw' erasure_code/gf_vect_mul_avx.asm:127: `vpsraw' previously defined here erasure_code/gf_vect_mul_avx.asm:129: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:130: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:131: instruction expected after label erasure_code/gf_vect_mul_avx.asm:132: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:133: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:134: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:135: instruction expected after label erasure_code/gf_vect_mul_avx.asm:136: redefinition of `vpxor' erasure_code/gf_vect_mul_avx.asm:135: `vpxor' previously defined here erasure_code/gf_vect_mul_avx.asm:137: instruction expected after label erasure_code/gf_vect_mul_avx.asm:138: redefinition of `vmovntdq' erasure_code/gf_vect_mul_avx.asm:137: `vmovntdq' previously defined here make[2]: *** [bin/gf_vect_mul_avx.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/opt/sheepdog/lib/isa-l' make[1]: *** [libisa.a] Error 2 make[1]: *** Waiting for unfinished jobs I switch to use v0.8.3 and it's OK. I'm not sure if it's a real problem or I miss something. I'd like to show you the software version of my environment if it is really needed. Thanks for your help~! Hu -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] Issues about setup
Hi Hu, At Fri, 16 Jan 2015 16:43:22 +0800, hujianyang wrote: Hi Hitoshi, I'm a learner of sheepdog. Here is two issues about setting up sheepdog in my environment. 1) invalid option '-d' in README To set up a 3 node cluster using local driver in one liner bash with debug mode: $ mkdir /path/to/store $ for i in 0 1 2; do sheep -c local -d /path/to/store/$i -z $i -p 700$i;sleep 1;done but: $ sheep -c local -d /mnt/store/0 -z 0 -p 7000 sheep: invalid option -- 'd' Try 'sheep --help' for more information. Seems '-d' is removed so maybe README file should be updated? As you noticed, -d is removed already. And the README file is very outdated. I have to update the file but I'm busy in these days. I'll do it later, but if you have time, could you post a patch for updating README? If you can help us, it is very helpful :) 2) compile error in version v0.9.0+ When compile sheepdog v0.9.0+, I met a lots of error messages below: yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_mul_sse.o erasure_code/gf_vect_mul_sse.asm --- Building erasure_code/gf_vect_mul_avx.asm yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_mul_avx.o erasure_code/gf_vect_mul_avx.asm --- Building erasure_code/gf_vect_dot_prod_sse.asm yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_dot_prod_sse.o erasure_code/gf_vect_dot_prod_sse.asm erasure_code/gf_vect_mul_avx.asm:116: instruction expected after label erasure_code/gf_vect_mul_avx.asm:117: instruction expected after label erasure_code/gf_vect_mul_avx.asm:118: redefinition of `vmovdqu' erasure_code/gf_vect_mul_avx.asm:117: `vmovdqu' previously defined here erasure_code/gf_vect_mul_avx.asm:121: instruction expected after label erasure_code/gf_vect_mul_avx.asm:122: redefinition of `vmovntdqa' erasure_code/gf_vect_mul_avx.asm:121: `vmovntdqa' previously defined here erasure_code/gf_vect_mul_avx.asm:125: instruction expected after label erasure_code/gf_vect_mul_avx.asm:126: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:127: instruction expected after label erasure_code/gf_vect_mul_avx.asm:128: redefinition of `vpsraw' erasure_code/gf_vect_mul_avx.asm:127: `vpsraw' previously defined here erasure_code/gf_vect_mul_avx.asm:129: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:130: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:131: instruction expected after label erasure_code/gf_vect_mul_avx.asm:132: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:133: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:134: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:135: instruction expected after label erasure_code/gf_vect_mul_avx.asm:136: redefinition of `vpxor' erasure_code/gf_vect_mul_avx.asm:135: `vpxor' previously defined here erasure_code/gf_vect_mul_avx.asm:137: instruction expected after label erasure_code/gf_vect_mul_avx.asm:138: redefinition of `vmovntdq' erasure_code/gf_vect_mul_avx.asm:137: `vmovntdq' previously defined here make[2]: *** [bin/gf_vect_mul_avx.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/opt/sheepdog/lib/isa-l' make[1]: *** [libisa.a] Error 2 make[1]: *** Waiting for unfinished jobs I switch to use v0.8.3 and it's OK. I'm not sure if it's a real problem or I miss something. I'd like to show you the software version of my environment if it is really needed. Hmm, could you show your yasm version? My yasm (1.2.0) can build current master branch with no problems. Thanks, Hitoshi -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] Issues about setup
On 2015/1/16 17:40, Hitoshi Mitake wrote: Hi Hu, At Fri, 16 Jan 2015 16:43:22 +0800, hujianyang wrote: Hi Hitoshi, I'm a learner of sheepdog. Here is two issues about setting up sheepdog in my environment. 1) invalid option '-d' in README To set up a 3 node cluster using local driver in one liner bash with debug mode: $ mkdir /path/to/store $ for i in 0 1 2; do sheep -c local -d /path/to/store/$i -z $i -p 700$i;sleep 1;done but: $ sheep -c local -d /mnt/store/0 -z 0 -p 7000 sheep: invalid option -- 'd' Try 'sheep --help' for more information. Seems '-d' is removed so maybe README file should be updated? As you noticed, -d is removed already. And the README file is very outdated. I have to update the file but I'm busy in these days. I'll do it later, but if you have time, could you post a patch for updating README? If you can help us, it is very helpful :) I'd like to, but I think I should know more about this filesystem first. Give me some time. 2) compile error in version v0.9.0+ When compile sheepdog v0.9.0+, I met a lots of error messages below: yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_mul_sse.o erasure_code/gf_vect_mul_sse.asm --- Building erasure_code/gf_vect_mul_avx.asm yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_mul_avx.o erasure_code/gf_vect_mul_avx.asm --- Building erasure_code/gf_vect_dot_prod_sse.asm yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_dot_prod_sse.o erasure_code/gf_vect_dot_prod_sse.asm erasure_code/gf_vect_mul_avx.asm:116: instruction expected after label erasure_code/gf_vect_mul_avx.asm:117: instruction expected after label erasure_code/gf_vect_mul_avx.asm:118: redefinition of `vmovdqu' erasure_code/gf_vect_mul_avx.asm:117: `vmovdqu' previously defined here erasure_code/gf_vect_mul_avx.asm:121: instruction expected after label erasure_code/gf_vect_mul_avx.asm:122: redefinition of `vmovntdqa' erasure_code/gf_vect_mul_avx.asm:121: `vmovntdqa' previously defined here erasure_code/gf_vect_mul_avx.asm:125: instruction expected after label erasure_code/gf_vect_mul_avx.asm:126: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:127: instruction expected after label erasure_code/gf_vect_mul_avx.asm:128: redefinition of `vpsraw' erasure_code/gf_vect_mul_avx.asm:127: `vpsraw' previously defined here erasure_code/gf_vect_mul_avx.asm:129: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:130: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:131: instruction expected after label erasure_code/gf_vect_mul_avx.asm:132: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:133: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:134: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:135: instruction expected after label erasure_code/gf_vect_mul_avx.asm:136: redefinition of `vpxor' erasure_code/gf_vect_mul_avx.asm:135: `vpxor' previously defined here erasure_code/gf_vect_mul_avx.asm:137: instruction expected after label erasure_code/gf_vect_mul_avx.asm:138: redefinition of `vmovntdq' erasure_code/gf_vect_mul_avx.asm:137: `vmovntdq' previously defined here make[2]: *** [bin/gf_vect_mul_avx.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/opt/sheepdog/lib/isa-l' make[1]: *** [libisa.a] Error 2 make[1]: *** Waiting for unfinished jobs I switch to use v0.8.3 and it's OK. I'm not sure if it's a real problem or I miss something. I'd like to show you the software version of my environment if it is really needed. Hmm, could you show your yasm version? My yasm (1.2.0) can build current master branch with no problems. # yasm --version yasm 0.6.2.1985 Compiled on Feb 23 2009. Copyright (c) 2001-2007 Peter Johnson and other Yasm developers. Run yasm --license for licensing overview and summary. I'm running on a very old SUSE11sp2. Thanks for your replay~! Hu -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] Issues about setup
At Fri, 16 Jan 2015 17:52:05 +0800, hujianyang wrote: On 2015/1/16 17:40, Hitoshi Mitake wrote: Hi Hu, At Fri, 16 Jan 2015 16:43:22 +0800, hujianyang wrote: Hi Hitoshi, I'm a learner of sheepdog. Here is two issues about setting up sheepdog in my environment. 1) invalid option '-d' in README To set up a 3 node cluster using local driver in one liner bash with debug mode: $ mkdir /path/to/store $ for i in 0 1 2; do sheep -c local -d /path/to/store/$i -z $i -p 700$i;sleep 1;done but: $ sheep -c local -d /mnt/store/0 -z 0 -p 7000 sheep: invalid option -- 'd' Try 'sheep --help' for more information. Seems '-d' is removed so maybe README file should be updated? As you noticed, -d is removed already. And the README file is very outdated. I have to update the file but I'm busy in these days. I'll do it later, but if you have time, could you post a patch for updating README? If you can help us, it is very helpful :) I'd like to, but I think I should know more about this filesystem first. Give me some time. Of couse :) 2) compile error in version v0.9.0+ When compile sheepdog v0.9.0+, I met a lots of error messages below: yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_mul_sse.o erasure_code/gf_vect_mul_sse.asm --- Building erasure_code/gf_vect_mul_avx.asm yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_mul_avx.o erasure_code/gf_vect_mul_avx.asm --- Building erasure_code/gf_vect_dot_prod_sse.asm yasm -f elf64 -D NDEBUG -Ierasure_code -Iinclude -o bin/gf_vect_dot_prod_sse.o erasure_code/gf_vect_dot_prod_sse.asm erasure_code/gf_vect_mul_avx.asm:116: instruction expected after label erasure_code/gf_vect_mul_avx.asm:117: instruction expected after label erasure_code/gf_vect_mul_avx.asm:118: redefinition of `vmovdqu' erasure_code/gf_vect_mul_avx.asm:117: `vmovdqu' previously defined here erasure_code/gf_vect_mul_avx.asm:121: instruction expected after label erasure_code/gf_vect_mul_avx.asm:122: redefinition of `vmovntdqa' erasure_code/gf_vect_mul_avx.asm:121: `vmovntdqa' previously defined here erasure_code/gf_vect_mul_avx.asm:125: instruction expected after label erasure_code/gf_vect_mul_avx.asm:126: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:127: instruction expected after label erasure_code/gf_vect_mul_avx.asm:128: redefinition of `vpsraw' erasure_code/gf_vect_mul_avx.asm:127: `vpsraw' previously defined here erasure_code/gf_vect_mul_avx.asm:129: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:130: redefinition of `vpand' erasure_code/gf_vect_mul_avx.asm:125: `vpand' previously defined here erasure_code/gf_vect_mul_avx.asm:131: instruction expected after label erasure_code/gf_vect_mul_avx.asm:132: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:133: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:134: redefinition of `vpshufb' erasure_code/gf_vect_mul_avx.asm:131: `vpshufb' previously defined here erasure_code/gf_vect_mul_avx.asm:135: instruction expected after label erasure_code/gf_vect_mul_avx.asm:136: redefinition of `vpxor' erasure_code/gf_vect_mul_avx.asm:135: `vpxor' previously defined here erasure_code/gf_vect_mul_avx.asm:137: instruction expected after label erasure_code/gf_vect_mul_avx.asm:138: redefinition of `vmovntdq' erasure_code/gf_vect_mul_avx.asm:137: `vmovntdq' previously defined here make[2]: *** [bin/gf_vect_mul_avx.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/opt/sheepdog/lib/isa-l' make[1]: *** [libisa.a] Error 2 make[1]: *** Waiting for unfinished jobs I switch to use v0.8.3 and it's OK. I'm not sure if it's a real problem or I miss something. I'd like to show you the software version of my environment if it is really needed. Hmm, could you show your yasm version? My yasm (1.2.0) can build current master branch with no problems. # yasm --version yasm 0.6.2.1985 Compiled on Feb 23 2009. Copyright (c) 2001-2007 Peter Johnson and other Yasm developers. Run yasm --license for licensing overview and summary. I'm running on a very old SUSE11sp2. OK. BTW, I'm using Ubuntu 14.04. This environment doesn't cause any problems. Thanks, Hitoshi Thanks for your replay~! Hu -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog -- sheepdog mailing list sheepdog@lists.wpkg.org https://lists.wpkg.org/mailman/listinfo/sheepdog
