Menu
▾
▴
moosefs-users — Mailing list for MooseFS Users
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(20) |
Feb
(11) |
Mar
(11) |
Apr
(9) |
May
(22) |
Jun
(85) |
Jul
(94) |
Aug
(80) |
Sep
(72) |
Oct
(64) |
Nov
(69) |
Dec
(89) |
| 2011 |
Jan
(72) |
Feb
(109) |
Mar
(116) |
Apr
(117) |
May
(117) |
Jun
(102) |
Jul
(91) |
Aug
(72) |
Sep
(51) |
Oct
(41) |
Nov
(55) |
Dec
(74) |
| 2012 |
Jan
(45) |
Feb
(77) |
Mar
(99) |
Apr
(113) |
May
(132) |
Jun
(75) |
Jul
(70) |
Aug
(58) |
Sep
(58) |
Oct
(37) |
Nov
(51) |
Dec
(15) |
| 2013 |
Jan
(28) |
Feb
(16) |
Mar
(25) |
Apr
(38) |
May
(23) |
Jun
(39) |
Jul
(42) |
Aug
(19) |
Sep
(41) |
Oct
(31) |
Nov
(18) |
Dec
(18) |
| 2014 |
Jan
(17) |
Feb
(19) |
Mar
(39) |
Apr
(16) |
May
(10) |
Jun
(13) |
Jul
(17) |
Aug
(13) |
Sep
(8) |
Oct
(53) |
Nov
(23) |
Dec
(7) |
| 2015 |
Jan
(35) |
Feb
(13) |
Mar
(14) |
Apr
(56) |
May
(8) |
Jun
(18) |
Jul
(26) |
Aug
(33) |
Sep
(40) |
Oct
(37) |
Nov
(24) |
Dec
(20) |
| 2016 |
Jan
(38) |
Feb
(20) |
Mar
(25) |
Apr
(14) |
May
(6) |
Jun
(36) |
Jul
(27) |
Aug
(19) |
Sep
(36) |
Oct
(24) |
Nov
(15) |
Dec
(16) |
| 2017 |
Jan
(8) |
Feb
(13) |
Mar
(17) |
Apr
(20) |
May
(28) |
Jun
(10) |
Jul
(20) |
Aug
(3) |
Sep
(18) |
Oct
(8) |
Nov
|
Dec
(5) |
| 2018 |
Jan
(15) |
Feb
(9) |
Mar
(12) |
Apr
(7) |
May
(123) |
Jun
(41) |
Jul
|
Aug
(14) |
Sep
|
Oct
(15) |
Nov
|
Dec
(7) |
| 2019 |
Jan
(2) |
Feb
(9) |
Mar
(2) |
Apr
(9) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(12) |
Dec
(2) |
| 2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(18) |
Oct
(2) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(5) |
Oct
(5) |
Nov
(3) |
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Aleksander W. <ale...@mo...> - 2016-03-02 08:09:28
|
Hi, Thank you for this information. All results look reasonable. Also I would like to add that you don't have problems with fork operation. Metadata dump process took: 24.561 seconds: Feb 29 10:00:24 mfs-CNC-GZSX-231 mfsmaster20936: store process has finished - store time: 24.561 The most alarming aspect in your system log is that all chunkservers disconnected at the same time and 34 seconds after metadata save: Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11537568169984 (10745.20 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11535864147968 (10743.61 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536655306752 (10744.35 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536570953728 (10744.27 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536672366592 (10744.36 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11537568169984 (10745.20 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536639004672 (10744.33 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536581537792 (10744.28 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536540909568 (10744.24 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238..*.* / port: 9422, usedspace: 11536369881088 (10744.08 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238..*.* / port: 9422, usedspace: 11536581566464 (10744.28 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238..*.* / port: 9422, usedspace: 11536586833920 (10744.28 GiB), totalspace: 22425943621632 (20885.79 GiB) Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster20936: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536620646400 (10744.32 GiB), totalspace: 22425943621632 (20885.79 GiB) Would you be so kind and send us logs from one chunkserver and client machines. We suspect that something is going on in your network. It's look like your master server loosing network connection. Please check your network configuration. We are waiting for your feedback. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> |
|
From: 彭智希 <pen...@16...> - 2016-03-02 01:09:41
|
Hi [root@mfs-CNC-GZSX-231 ~]# cat /proc/sys/vm/overcommit_memory 1 [root@mfs-CNC-GZSX-231 ~]# cat /etc/sysctl.conf net.ipv4.ip_forward = 0 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.all.log_martians = 1 kernel.sysrq = 0 net.ipv4.neigh.default.gc_thresh1 = 8192 net.ipv4.neigh.default.gc_thresh2 = 4092 net.ipv4.neigh.default.gc_thresh3 = 8192 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1 #####vm.max_map_count = 6553000 fs.file-max = 819200 ########## #####TCP sockets net.ipv4.tcp_max_orphans = 400000 #######syn cookies net.ipv4.tcp_max_syn_backlog = 400000 net.ipv4.tcp_syn_retries = 3 net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_syncookies = 1 ######## ########TIME_WAIT net.ipv4.tcp_max_tw_buckets = 1440000 net.ipv4.tcp_tw_recycle=0 net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_timestamps = 1 ######## net.ipv4.tcp_fin_timeout = 15 net.ipv4.tcp_keepalive_time = 300 net.core.netdev_max_backlog = 400000 net.ipv4.ip_local_port_range = 1024 65535 ######## net.core.rmem_max = 9174960 net.core.rmem_default = 9174960 net.core.wmem_max = 9174960 net.core.wmem_default = 9174960 net.core.optmem_max = 921600 net.ipv4.tcp_rmem = 28192 565248 819200 net.ipv4.tcp_wmem = 14096 141312 409600 ########### net.ipv4.ipfrag_high_thresh = 5242880 net.ipv4.tcp_slow_start_after_idle = 0 #net.ipv4.tcp_westwood = 1 #net.ipv4.tcp_bic = 1 net.ipv4.ipfrag_low_thresh = 2932160 ################# net.core.somaxconn = 400000 ######################### vm.swappiness = 0 ###Version 2014.05.26 ###### net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_low_latency = 0 net.ipv4.tcp_slow_start_after_idle = 0 ######core kernel.core_pattern = /var/core/core.%e-%p-%t At 2016-03-01 19:07:11, "Aleksander Wieliczko" <ale...@mo...> wrote: >Hi, >Thank you for this information. > >Would you be so kind end check if you have enabled overcommit_memory in >your system? >This command should return 1: >cat /proc/sys/vm/overcommit_memory > >Also can you send us results from command: >cat /etc/sysctl.conf > >Best regards >Aleksander Wieliczko >Technical Support Engineer >MooseFS.com <moosefs.com> |
|
From: Aleksander W. <ale...@mo...> - 2016-03-01 11:07:26
|
Hi, Thank you for this information. Would you be so kind end check if you have enabled overcommit_memory in your system? This command should return 1: cat /proc/sys/vm/overcommit_memory Also can you send us results from command: cat /etc/sysctl.conf Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> |
|
From: 彭智希 <pen...@16...> - 2016-03-01 09:48:30
|
Hi it is only used for mfsmaster, no more MooseFS components! [root@mfs-CNC-GZSX-231 mfs]# free -l total used free shared buff/cache available Mem: 65774444 12521016 35433164 3361080 17820264 49476984 Low: 65774444 30341280 35433164 High: 0 0 0 Swap: 16777212 0 16777212 At 2016-03-01 15:55:11, "Aleksander Wieliczko" <ale...@mo...> wrote: >Hi, >I have another question for you. > >Your 64G master server is used only for MooseFS master or you have other >MooseFS components, or some other applications like virtual machines? > > >Best regards >Aleksander Wieliczko >Technical Support Engineer >MooseFS.com |
|
From: Aleksander W. <ale...@mo...> - 2016-03-01 07:55:20
|
Hi, I have another question for you. Your 64G master server is used only for MooseFS master or you have other MooseFS components, or some other applications like virtual machines? Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com |
|
From: 彭智希 <pen...@16...> - 2016-03-01 01:36:19
|
Hello all:
the information of environment list at below:
OS: centos 7.1
Version of Mfs: 2.0.68
I cut some log information as below:
Feb 29 09:58:29 mfs-CNC-GZSX-231 mfsmaster[20936]: chunk 00000000022688C8_00000001: there are no copies
Feb 29 09:59:56 mfs-CNC-GZSX-231 mfsmaster[20936]: chunk 0000000002B76EEC_00000001: there are no copies
Feb 29 10:00:00 mfs-CNC-GZSX-231 mfsmaster[20936]: no metaloggers connected !!!
Feb 29 10:00:02 mfs-CNC-GZSX-231 mfsmaster[20936]: chunk 0000000002004141_00000001: there are no copies
Feb 29 10:00:23 mfs-CNC-GZSX-231 mfsmaster[20936]: chunk 0000000000F1F567_00000001: there are no copies
Feb 29 10:00:24 mfs-CNC-GZSX-231 mfsmaster[20936]: child finished
Feb 29 10:00:24 mfs-CNC-GZSX-231 mfsmaster[20936]: store process has finished - store time: 24.561
Feb 29 10:00:25 mfs-CNC-GZSX-231 mfsmaster[20936]: chunk 0000000000EB84BA_00000001: there are no copies
Feb 29 10:00:26 mfs-CNC-GZSX-231 mfsmaster[20936]: chunk 0000000000F4E3A7_00000001: there are no copies
Feb 29 10:00:29 mfs-CNC-GZSX-231 mfsmaster[20936]: chunk 0000000000ED73C0_00000001: there are no copies
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: main master server module: (ip:115.238.*.*) write error: EPIPE (Broken pipe)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,5), but server is still connected
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: can't accept chunkserver (ip: 115.238.*.* / port: 9422)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11537568169984 (10745.20 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11535864147968 (10743.61 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536655306752 (10744.35 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536570953728 (10744.27 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536672366592 (10744.36 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11537568169984 (10745.20 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536639004672 (10744.33 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536581537792 (10744.28 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536540909568 (10744.24 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238..*.* / port: 9422, usedspace: 11536369881088 (10744.08 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238..*.* / port: 9422, usedspace: 11536581566464 (10744.28 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238..*.* / port: 9422, usedspace: 11536586833920 (10744.28 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver disconnected - ip: 115.238.*.* / port: 9422, usedspace: 11536620646400 (10744.32 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,11)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536672366592 (10744.36 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,8)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536570953728 (10744.27 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,9)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536655306752 (10744.35 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,3)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11535864147968 (10743.61 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.231.144:9422,1)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536620646400 (10744.32 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,10)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536586833920 (10744.28 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,12)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536369881088 (10744.08 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.231.151:9422,6)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536581566464 (10744.28 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,4)
Feb 29 10:00:58 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536540909568 (10744.24 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:59 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,2)
Feb 29 10:00:59 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536581537792 (10744.28 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:00:59 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,7)
Feb 29 10:00:59 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11536639004672 (10744.33 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:01:00 mfs-CNC-GZSX-231 mfsmaster[20936]: csdb: found cs using ip:port and csid (115.238.*.*:9422,5)
Feb 29 10:01:00 mfs-CNC-GZSX-231 mfsmaster[20936]: chunkserver register begin (packet version: 6) - ip: 115.238.*.* / port: 9422, usedspace: 11537568169984 (10745.20 GiB), totalspace: 22425943621632 (20885.79 GiB)
Feb 29 10:01:12 mfs-CNC-GZSX-231 mfsmaster[20936]: server ip: 115.238.*.* / port: 9422 has been fully removed from data structures
At 2016-03-01 01:34:49, "Piotr Robert Konopelko" <pio...@mo...> wrote:
Hello 彭智希,
could you please send us logs from Master Server while such situation happens?
cat /var/log/syslog | grep mfsmaster
or
cat /var/log/messages | grep mfsmaster
Which operating system are you using exactly?
Debian? Ubuntu? CentOS? Which version?
Which exactly version of MooseFS Master are you ruuning? 2.0.x, x=?
Best regards,
--
Piotr Robert Konopelko
MooseFS Technical Support Engineer
e-mail : pio...@mo...
www : https://moosefs.com
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email.
On 29 Feb 2016, at 8:25 AM, 彭智希 <pen...@16...> wrote:
dear all:
I use the version of 2.0 and i found that the master can't server any request at every o'clock. It gets righter 3-4 minutes later. I do it according to the solution of https://sourceforge.net/p/moosefs/mailman/message/34310363/, but the result is not satisfied. There is 64G memory total. So i think the memory is enough.
The file of metadata.mfs.back is about 4.3G. It is able to or not too big to image the metadate to disk for the child process? I hope any body could give me some hints!
Thanks!!
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_________________________________________
moosefs-users mailing list
moo...@li...
https://lists.sourceforge.net/lists/listinfo/moosefs-users
|
|
From: Piotr R. K. <pio...@mo...> - 2016-02-29 17:35:08
|
Hello 彭智希, could you please send us logs from Master Server while such situation happens? cat /var/log/syslog | grep mfsmaster or cat /var/log/messages | grep mfsmaster Which operating system are you using exactly? Debian? Ubuntu? CentOS? Which version? Which exactly version of MooseFS Master are you ruuning? 2.0.x, x=? Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 29 Feb 2016, at 8:25 AM, 彭智希 <pen...@16...> wrote: > > dear all: > I use the version of 2.0 and i found that the master can't server any request at every o'clock. It gets righter 3-4 minutes later. I do it according to the solution of https://sourceforge.net/p/moosefs/mailman/message/34310363/ <https://sourceforge.net/p/moosefs/mailman/message/34310363/>, but the result is not satisfied. There is 64G memory total. So i think the memory is enough. > The file of metadata.mfs.back is about 4.3G. It is able to or not too big to image the metadate to disk for the child process? I hope any body could give me some hints! > Thanks!! > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Piotr R. K. <pio...@mo...> - 2016-02-29 17:14:26
|
Just forwarding the e-mail, because the user is not subscribed to MooseFS-Users list. Regards, Piotr Robert Konopelko > Begin forwarded message: > > From: "Ricardo J. Barberis" <ric...@do...> > Subject: Re: [MooseFS-Users] why master can't server any request at every o'clock? > Date: 29 February 2016 at 5:42:02 PM GMT+1 > To: moo...@li... > > El Lunes 29/02/2016, 彭智希 escribió: >> dear all: >> I use the version of 2.0 and i found that the master can't server any >> request at every o'clock. It gets righter 3-4 minutes later. I do it >> according to the solution of >> https://sourceforge.net/p/moosefs/mailman/message/34310363/, but the result >> is not satisfied. There is 64G memory total. So i think the memory is >> enough. The file of metadata.mfs.back is about 4.3G. It is able to or not >> too big to image the metadate to disk for the child process? I hope any >> body could give me some hints! Thanks!! > > Probably a slow disk? Check the status of your disk, like latency, IOPS, etc. > > If possible, put metadata.mfs in a SSD disk and make sure your partitions are > correctly aligned, especially if your disk uses 4K sectors, e.g.: > > # parted --script /dev/sdX align-check optimal N > > Where you have to replace sdX with your disk name and N with the partition > number you want to check (iterate for every partition on your disk). > > If the partitions are correctly aligned, parted should give you no output. > > Cheers, > -- > Ricardo J. Barberis > Senior SysAdmin / IT Architect > DonWeb > La Actitud Es Todo > www.DonWeb.com > _____ |
|
From: Ricardo J. B. <ric...@do...> - 2016-02-29 17:03:04
|
El Lunes 29/02/2016, 彭智希 escribió: > dear all: > I use the version of 2.0 and i found that the master can't server any > request at every o'clock. It gets righter 3-4 minutes later. I do it > according to the solution of > https://sourceforge.net/p/moosefs/mailman/message/34310363/, but the result > is not satisfied. There is 64G memory total. So i think the memory is > enough. The file of metadata.mfs.back is about 4.3G. It is able to or not > too big to image the metadate to disk for the child process? I hope any > body could give me some hints! Thanks!! Probably a slow disk? Check the status of your disk, like latency, IOPS, etc. If possible, put metadata.mfs in a SSD disk and make sure your partitions are correctly aligned, especially if your disk uses 4K sectors, e.g.: # parted --script /dev/sdX align-check optimal N Where you have to replace sdX with your disk name and N with the partition number you want to check (iterate for every partition on your disk). If the partitions are correctly aligned, parted should give you no output. Cheers, -- Ricardo J. Barberis Senior SysAdmin / IT Architect DonWeb La Actitud Es Todo www.DonWeb.com _____ |
|
From: 彭智希 <pen...@16...> - 2016-02-29 07:42:05
|
dear all: I use the version of 2.0 and i found that the master can't server any request at every o'clock. It gets righter 3-4 minutes later. I do it according to the solution of https://sourceforge.net/p/moosefs/mailman/message/34310363/, but the result is not satisfied. There is 64G memory total. So i think the memory is enough. The file of metadata.mfs.back is about 4.3G. It is able to or not too big to image the metadate to disk for the child process? I hope any body could give me some hints! Thanks!! |
|
From: 彭智希 <pen...@16...> - 2016-02-29 07:25:19
|
dear all: I use the version of 2.0 and i found that the master can't server any request at every o'clock. It gets righter 3-4 minutes later. I do it according to the solution of https://sourceforge.net/p/moosefs/mailman/message/34310363/, but the result is not satisfied. There is 64G memory total. So i think the memory is enough. The file of metadata.mfs.back is about 4.3G. It is able to or not too big to image the metadate to disk for the child process? I hope any body could give me some hints! Thanks!! |
|
From: Wilson, S. M <st...@pu...> - 2016-02-17 13:16:00
|
On Wed, 2016-02-17 at 03:09 +0100, Piotr Robert Konopelko wrote: Hi Steven, I have a suggested improvement for mfsdirinfo. It would be good if it could handle hard links so that file size is only counted once for each file that has multiple hard links. For example, if I create a directory (named "testdir") with a ~1GB file in it and then type "mfsdirinfo -s testdir" I will see that the size is 1028734976. Now if I create a hard link to that file in "testdir" and re-run the mfsdirinfo command I'll see that the size of the directory is now doubled to 2057469952. I would like the behavior to be the same as the du command which shows the same size before and after making the hard link. Actually we were working on such feature at the same time you thought about it :) It has been introduced since MFS 3.0.73. Great! I'm looking forward to moving to 3.x once it becomes stable. Another suggestion for mfsdirinfo would be to add an option like the "-L" option (dereference symbolic links) to the du command. This would allow me to get accurate space usage summaries even though some of the lower-level directories might be symbolic links. Oh, it is not implemented yet, but it is a great feature. We'll think on adding this in the future. And perhaps implied by this would be something similar to the "-x" option (skip directories on different file systems) so that the user could choose whether sym links should be followed to other file systems or not. Thanks! Steve |
|
From: Piotr R. K. <pio...@mo...> - 2016-02-17 02:09:17
|
Hi Steven, > I have a suggested improvement for mfsdirinfo. It would be good if it could handle hard links so that file size is only counted once for each file that has multiple hard links. For example, if I create a directory (named "testdir") with a ~1GB file in it and then type "mfsdirinfo -s testdir" I will see that the size is 1028734976. Now if I create a hard link to that file in "testdir" and re-run the mfsdirinfo command I'll see that the size of the directory is now doubled to 2057469952. I would like the behavior to be the same as the du command which shows the same size before and after making the hard link. Actually we were working on such feature at the same time you thought about it :) It has been introduced since MFS 3.0.73. MooseFS 3.0.73-1 (2016-02-11) [...] (tools) added '-p' option to 'mfsdirinfo' - 'precise mode' [...] Running mfsdirinfo -p can show you more precise space usage, it is able not to count hardlinks and snapshots, but can be time-consuming. > Another suggestion for mfsdirinfo would be to add an option like the "-L" option (dereference symbolic links) to the du command. This would allow me to get accurate space usage summaries even though some of the lower-level directories might be symbolic links. Oh, it is not implemented yet, but it is a great feature. We'll think on adding this in the future. PS: mfsdirinfo unfortunately may not count sparse files properly (it may report a bit higher values). Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 11 Feb 2016, at 7:39 PM, Wilson, Steven M <st...@pu...> wrote: > > Hi, > > I have a suggested improvement for mfsdirinfo. It would be good if it could handle hard links so that file size is only counted once for each file that has multiple hard links. For example, if I create a directory (named "testdir") with a ~1GB file in it and then type "mfsdirinfo -s testdir" I will see that the size is 1028734976. Now if I create a hard link to that file in "testdir" and re-run the mfsdirinfo command I'll see that the size of the directory is now doubled to 2057469952. I would like the behavior to be the same as the du command which shows the same size before and after making the hard link. > > Another suggestion for mfsdirinfo would be to add an option like the "-L" option (dereference symbolic links) to the du command. This would allow me to get accurate space usage summaries even though some of the lower-level directories might be symbolic links. > > Thanks! |
|
From: Piotr R. K. <pio...@mo...> - 2016-02-12 17:22:55
|
Hi, > By the way, in theory the chunks of a file whose goal is set to 2 are stored in different server or just different disk? They are stored on different chunkservers. It is one of principals of MooseFS. So e.g. if you want to store files in goal 4, you have to have minimum 4 different chunkservers. Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 12 Feb 2016, at 6:18 PM, hanyuwei70 <han...@vi...> wrote: > > Thanks for your advice. I will try it after the server restored ( I can't access the server room now). > By the way, in theory the chunks of a file whose goal is set to 2 are stored in different server or just different disk? > > > ------------------ Original ------------------ > From: "Piotr Robert Konopelko";<pio...@mo...>; > Date: Sat, Feb 13, 2016 01:10 AM > To: "hanyuwei70"<han...@vi...>; > Cc: "moosefs-users"<moo...@li...>; > Subject: Re: [MooseFS-Users] Lots of missing file in single server fault > > Hi, > > 1. Put all servers up. > 2. Set the goal to 2: mfssetgoal -r 2 /mnt/mfs > 3. Wait for chunks to replicate (you should not see any chunks in goal 2 in MFS CGI) > > > Best regards, > > -- > > <0206E94A@DB335031.0214BE56> <https://moosefs.com/> > > Piotr Robert Konopelko > MooseFS Technical Support Engineer > e-mail : pio...@mo... <mailto:pio...@mo...> > www : https://moosefs.com <https://moosefs.com/> > > <A0004D7E@DB335031.0214BE56> <https://twitter.com/MooseFS><6D3DBB81@DB335031.0214BE56> <https://www.facebook.com/moosefs><29E01238@DB335031.0214BE56> <https://www.linkedin.com/company/moosefs><FB0E167D@DB335031.0214BE56> <https://github.com/moosefs> > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > > >> On 12 Feb 2016, at 4:28 PM, hanyuwei70 <han...@vi... <mailto:han...@vi...>> wrote: >> >> My mfs cluster is multiple server and each server has multiple disks. Now some of them are unstable, so there is a lot of situation that one server is down for various reasons. But I discovered that though I set goal to 2 for every file, there still have some missing file when one server is down. So now I want to keep access to every file in single server fault, what should I config? >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_________________________________________ <http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_________________________________________> >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > |
|
From: Piotr R. K. <pio...@mo...> - 2016-02-12 17:10:22
|
Hi, 1. Put all servers up. 2. Set the goal to 2: mfssetgoal -r 2 /mnt/mfs 3. Wait for chunks to replicate (you should not see any chunks in goal 2 in MFS CGI) Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 12 Feb 2016, at 4:28 PM, hanyuwei70 <han...@vi...> wrote: > > My mfs cluster is multiple server and each server has multiple disks. Now some of them are unstable, so there is a lot of situation that one server is down for various reasons. But I discovered that though I set goal to 2 for every file, there still have some missing file when one server is down. So now I want to keep access to every file in single server fault, what should I config? > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: h. <han...@vi...> - 2016-02-12 15:44:54
|
My mfs cluster is multiple server and each server has multiple disks. Now some of them are unstable, so there is a lot of situation that one server is down for various reasons. But I discovered that though I set goal to 2 for every file, there still have some missing file when one server is down. So now I want to keep access to every file in single server fault, what should I config? |
|
From: Wilson, S. M <st...@pu...> - 2016-02-12 13:09:32
|
Thanks! Steve On Fri, 2016-02-12 at 12:25 +0100, Piotr Robert Konopelko wrote: Dear Steven, we forgot to let you know, that the problem is resolved since MooseFS 2.0.84: * MooseFS 2.0.84-1 (2016-01-19) - (mount) fixed setting file length in write module during truncate (fixes "git svn" case) Best regards, -- [MooseFS]<https://moosefs.com> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo...<mailto:pio...@mo...> www : https://moosefs.com [Twitter]<https://twitter.com/MooseFS> <https://twitter.com/MooseFS> [Facebook] <https://www.facebook.com/moosefs> <https://www.facebook.com/moosefs> [LinkedIn] <https://www.linkedin.com/company/moosefs> <https://www.linkedin.com/company/moosefs> [GitHub] <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. On 15 Jan 2016, at 2:57 PM, Wilson, Steven M <st...@pu...<mailto:st...@pu...>> wrote: Thanks, Aleksander. I'm glad to hear that you were able to duplicate the problem and are working to fix it. Best regards, Steve On Fri, 2016-01-15 at 12:29 +0100, Aleksander Wieliczko wrote: Hi, First of all we would like to thanks for reporting this issue. We can confirm that problem appears in mfsmount 2.0.72 and even in the latest release 2.0.83. Problem not occurred in MooseFS mount 3.0.69. Right now we are working to solve this problem. We will inform you about progress of our work. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com<x-msg://18/moosefs.com> On 01/14/2016 11:37 PM, Wilson, Steven M wrote: Hi, When I attempt to fetch an SVN repository using the "git svn fetch" command, it always fails when writing to a MooseFS volume. At some point during the process I get a "checksum mismatch" error like the following: Checksum mismatch: testmails/positive/348 expected: 42723d0ae0353368e9adb648da2eb6bc got: 637d201f8f22d9d71ba12bf7f39f14c8 I've tried this on two different MooseFS volumes from different servers (running MooseFS v. 2.0.72) with the same results. If I fetch to a local disk formatted in XFS, though, I don't get a checksum error. These are the commands that initially demonstrated the problem for me: git svn init http://emg.nysbc.org/svn/myami -s git svn fetch But I've since tested it with Spamassassin and had the same results: git svn init --prefix=origin/ -s https://svn.apache.org/repos/asf/spamassassin git svn fetch Could someone try this out on their own MooseFS installation to see if it also gives checksum errors? Is this a known bug? Thanks! Steve ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_________________________________________ moosefs-users mailing list moo...@li... https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Piotr R. K. <pio...@mo...> - 2016-02-12 11:25:54
|
Dear Steven, we forgot to let you know, that the problem is resolved since MooseFS 2.0.84: * MooseFS 2.0.84-1 (2016-01-19) - (mount) fixed setting file length in write module during truncate (fixes "git svn" case) Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 15 Jan 2016, at 2:57 PM, Wilson, Steven M <st...@pu...> wrote: > > Thanks, Aleksander. I'm glad to hear that you were able to duplicate the problem and are working to fix it. > > Best regards, > Steve > > On Fri, 2016-01-15 at 12:29 +0100, Aleksander Wieliczko wrote: >> Hi, >> >> First of all we would like to thanks for reporting this issue. >> We can confirm that problem appears in mfsmount 2.0.72 and even in the latest release 2.0.83. >> Problem not occurred in MooseFS mount 3.0.69. >> >> Right now we are working to solve this problem. >> We will inform you about progress of our work. >> >> Best regards >> Aleksander Wieliczko >> Technical Support Engineer >> MooseFS.com <x-msg://18/moosefs.com> >> >> >> On 01/14/2016 11:37 PM, Wilson, Steven M wrote: >> >>> Hi, >>> >>> When I attempt to fetch an SVN repository using the "git svn fetch" command, it always fails when writing to a MooseFS volume. At some point during the process I get a "checksum mismatch" error like the following: >>> Checksum mismatch: testmails/positive/348 >>> expected: 42723d0ae0353368e9adb648da2eb6bc >>> got: 637d201f8f22d9d71ba12bf7f39f14c8 >>> >>> I've tried this on two different MooseFS volumes from different servers (running MooseFS v. 2.0.72) with the same results. If I fetch to a local disk formatted in XFS, though, I don't get a checksum error. These are the commands that initially demonstrated the problem for me: >>> git svn init http://emg.nysbc.org/svn/myami <http://emg.nysbc.org/svn/myami> -s >>> git svn fetch >>> >>> But I've since tested it with Spamassassin and had the same results: >>> git svn init --prefix=origin/ -s https://svn.apache.org/repos/asf/spamassassin <https://svn.apache.org/repos/asf/spamassassin> >>> git svn fetch >>> >>> Could someone try this out on their own MooseFS installation to see if it also gives checksum errors? Is this a known bug? >>> >>> Thanks! >>> >>> Steve > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Wilson, S. M <st...@pu...> - 2016-02-11 18:40:05
|
Hi, I have a suggested improvement for mfsdirinfo. It would be good if it could handle hard links so that file size is only counted once for each file that has multiple hard links. For example, if I create a directory (named "testdir") with a ~1GB file in it and then type "mfsdirinfo -s testdir" I will see that the size is 1028734976. Now if I create a hard link to that file in "testdir" and re-run the mfsdirinfo command I'll see that the size of the directory is now doubled to 2057469952. I would like the behavior to be the same as the du command which shows the same size before and after making the hard link. Another suggestion for mfsdirinfo would be to add an option like the "-L" option (dereference symbolic links) to the du command. This would allow me to get accurate space usage summaries even though some of the lower-level directories might be symbolic links. Thanks! Steve |
|
From: WK <wk...@bn...> - 2016-02-06 03:36:11
|
On 2/5/2016 7:27 PM, Piotr Robert Konopelko wrote: > Hello, > > did Master dump the metadata file on disk properly during stop? not sure. I can try again > Do you have enough free space in /var/lib/mfs? > yes > If you're using CentOS with systemd, and have a lot of metadata, it > probably is connected with killing mfsmaster during metadata loading. yes it is CentOS7 > It was fixed in 3.0.69 and in "corresponding" fixed version of 2.x > branch - 2.0.83 > > MooseFS 3.0.60-1 (2015-11-23) > > * (systemd) added TimeoutStartSec=1800 to master > > (https://moosefs.com/documentation/changes-in-moosefs-3-0.html) > > > We noticed an issue with this in the middle of November 2015. > > >> |TimeoutStartSec=| >> Configures the time to wait for start-up. If a daemon service does >> not signal start-up completion within the configured time, the >> service will be considered failed and will be shut down again. Takes >> a unit-less value in seconds, or a time span value such as "5min >> 20s". Pass "|0|" to disable the timeout logic. Defaults to >> |DefaultTimeoutStartSec=| from the manager configuration file, except >> when |Type=oneshot| is used, in which case the timeout is disabled by >> default (see systemd-system.conf(5) >> <http://www.freedesktop.org/software/systemd/man/systemd-system.conf.html>). > > > > My advice is (first - make sure you have enough free space in > /var/lib/mfs) > > 1. to run mfsmaster -a, which creates a metadata.mfs file from last > successfully saved metadata.mfs + changelogs and starts Master Server. > 2. *to upgrade your Master Server to the latest stable version, > 2.0.84, which resolves the issue.* > > > > By the way: such behaviour will not occur if you run mfsmaster not via > starting script, but just issuing a mfsmaster start command. > > actually I was manually using the /usr/sbin/mfsmaster command. I will upgrade to lastest 2.x version and do a proper dump, this weekend. It appears that I am not in danger as of yet, as I do have metalogger metadata as well. -wk |
|
From: Piotr R. K. <pio...@mo...> - 2016-02-06 03:36:00
|
Hi, I'd like to inform, that MooseFS 2.0.x is available in FreeBSD ports collection for over a six months :) Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 23 Mar 2015, at 8:59 AM, Akhobadze Alexander <akh...@ri...> wrote: > > > Hi All! > Unfortunately in the FreeBSD ports collection there is a 1.6.27-5 version of the moosefs port :--( > Is it planned to update it ? > > Wbr Alexander > > ====================================================== > > Hi, > > The update from 2.0.x CE version to 2.0.60 is similar to upgrade from 1.6.x. You need to remove old packages and install 2.0.60 that should start with all config and metadata files from previous version. > > We recommend starting from the master server. > > Before any deinstallation/installationplease make sure that you have valid backup of your config files and metadata files. > > ------ > Pozdrawiam, > Krzysztof Kielak > > -----Original Message----- > From: "Neddy, NH. Nam" <na...@nd...> > Date: Sat, 21 Mar 2015 08:18:16 > Cc: moo...@li...<moo...@li...> > Subject: Re: [MooseFS-Users] MooseFS 2.0.60-1 released and back on GPL > > Hi, > > I'm using MooseFS CE and was trying to update to 2.0.60 but can't, > because the package names were changed (from moosefs-ce-xxx to > moosefs-xxx). Do I have to rebuild the whole FS? > > On Sat, Mar 21, 2015 at 2:12 AM, WK <wk...@bn...> wrote: >> Excellent, Excellent. >> >> We are still on 1.6.27. >> >> Can we directly upgrade to 2.0.60 or is there a recommended intermediate >> step. >> >> -wk >> >> On 3/20/2015 11:40 AM, Davies Liu wrote: >>> This is great news! >>> >>> I had created a git mirror for recent releases to track the changes: >>> https://github.com/davies/moosefs/commits/master >>> >>> On Fri, Mar 20, 2015 at 7:48 AM, Aleksander Wieliczko >>> <ale...@mo...> wrote: >>>> Hi. >>>> Yes change log is available on moosefs.org site >>>> >>>> http://www.moosefs.org/changelog.html >>>> >>>> Best regards >>>> Aleksander Wieliczko >>>> Technical Support Engineer >>>> MooseFS.com >>>> >>>> On 03/20/2015 03:42 PM, Steve Wilson wrote: >>>> >>>> Hi, >>>> >>>> Is there some form of release notes indicating the features and bug fixes >>>> included in this release? >>>> >>>> Thanks! >>>> >>>> Steve >>>> >>>> On 03/20/2015 10:25 AM, Krzysztof Kielak wrote: >>>> >>>> Dear MooseFS Community, >>>> >>>> We are very excited to announce that MooseFS is back on GPL license. >>>> >>>> From now on the MooseFS naming convention and licensing changes, so MooseFS >>>> CE (Community Edition) will now be referred to as MooseFS. >>>> >>>> MooseFS 2.0.60 (previously named CE) released today and all upcoming >>>> releases will be licensed under GPLv2. The change is our response to the >>>> feedback that we have got from the community after moving to proprietary >>>> license while introducing version 2.x. >>>> >>>> MooseFS PRO name and licensing will stay unchanged. >>>> >>>> Version 2.0.60 is the most stable and reliable release of 2.x branch and >>>> becomes a natural bridge to version 3.x planned to be released later this >>>> month. >>>> >>>> For more informations on installation or update procedures please visit >>>> https://moosefs.com/download.html >>>> >>>> Best Regards, >>>> MooseFS Team > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Piotr R. K. <pio...@mo...> - 2016-02-06 03:31:13
|
Oh, I forgot to add: The error you get is because Master during startup first of all renames found metadata.mfs to metadata.mfs.back, and if it was started, renamed it, then got killed, but file is renamed and in the second startup it can't find metadata.mfs. (Of course I still assume that this is connected with the problem I described). Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 06 Feb 2016, at 4:27 AM, Piotr Robert Konopelko <pio...@mo...> wrote: > > Hello, > > did Master dump the metadata file on disk properly during stop? > Do you have enough free space in /var/lib/mfs? > > If you're using CentOS with systemd, and have a lot of metadata, it probably is connected with killing mfsmaster during metadata loading. > It was fixed in 3.0.69 and in "corresponding" fixed version of 2.x branch - 2.0.83 > > MooseFS 3.0.60-1 (2015-11-23) > (systemd) added TimeoutStartSec=1800 to master > (https://moosefs.com/documentation/changes-in-moosefs-3-0.html <https://moosefs.com/documentation/changes-in-moosefs-3-0.html>) > > > We noticed an issue with this in the middle of November 2015. > >> TimeoutStartSec= >> Configures the time to wait for start-up. If a daemon service does not signal start-up completion within the configured time, the service will be considered failed and will be shut down again. Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass "0" to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the manager configuration file, except when Type=oneshot is used, in which case the timeout is disabled by default (see systemd-system.conf(5) <http://www.freedesktop.org/software/systemd/man/systemd-system.conf.html>). > > If you have a lot of metadata, it might take too long to load > it from disk and not reporting started status, so the daemon just > gets stopped prematurely. > > Please take a look at diff between startup scripts: > > [ok][2016-02-06][04:23:58][oxide94][Ionic][~/Desktop/rpm] > $ diff -ruN 2.0.81/usr/lib/systemd/system/moosefs-master.service 2.0.83/usr/lib/systemd/system/moosefs-master.service > --- 2.0.81/usr/lib/systemd/system/moosefs-master.service 2015-10-30 06:49:12.000000000 +0100 > +++ 2.0.83/usr/lib/systemd/system/moosefs-master.service 2016-01-08 11:05:15.000000000 +0100 > @@ -10,6 +10,7 @@ > ExecReload=/usr/sbin/mfsmaster reload > PIDFile=/var/lib/mfs/.mfsmaster.lock > TimeoutStopSec=1800 > +TimeoutStartSec=1800 > Restart=no > > [Install] > [err][2016-02-06][04:24:07][oxide94][Ionic][~/Desktop/rpm] > > > My advice is (first - make sure you have enough free space in /var/lib/mfs) > to run mfsmaster -a, which creates a metadata.mfs file from last successfully saved metadata.mfs + changelogs and starts Master Server. > to upgrade your Master Server to the latest stable version, 2.0.84, which resolves the issue. > > > By the way: such behaviour will not occur if you run mfsmaster not via starting script, but just issuing a mfsmaster start command. > > > Best regards, > > -- > > <Mail Attachment.png> <https://moosefs.com/> > > Piotr Robert Konopelko > MooseFS Technical Support Engineer > e-mail : pio...@mo... <mailto:pio...@mo...> > www : https://moosefs.com <https://moosefs.com/> > > <Mail Attachment.png> <https://twitter.com/MooseFS><Mail Attachment.png> <https://www.facebook.com/moosefs><Mail Attachment.png> <https://www.linkedin.com/company/moosefs><Mail Attachment.png> <https://github.com/moosefs> > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > > >> On 06 Feb 2016, at 1:50 AM, WK <wk...@bn... <mailto:wk...@bn...>> wrote: >> >> got this when I restarted mfsmaster on a 2.0.76 cluster very >> stock/default config >> >> >> can't rename metadata.mfs -> metadata.mfs.back: ENOENT (No such file or >> directory) >> >> The data seems ok, but sure enough there is not a metadata.mfs /var/lib/mfs >> >> Changelogs are there. >> metadata.mfs.back (.1) is there. >> >> Should I be worried? >> >> -wk >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 <http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140> >> _________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > |
|
From: Piotr R. K. <pio...@mo...> - 2016-02-06 03:27:52
|
Hello, did Master dump the metadata file on disk properly during stop? Do you have enough free space in /var/lib/mfs? If you're using CentOS with systemd, and have a lot of metadata, it probably is connected with killing mfsmaster during metadata loading. It was fixed in 3.0.69 and in "corresponding" fixed version of 2.x branch - 2.0.83 MooseFS 3.0.60-1 (2015-11-23) (systemd) added TimeoutStartSec=1800 to master (https://moosefs.com/documentation/changes-in-moosefs-3-0.html <https://moosefs.com/documentation/changes-in-moosefs-3-0.html>) We noticed an issue with this in the middle of November 2015. > TimeoutStartSec= > Configures the time to wait for start-up. If a daemon service does not signal start-up completion within the configured time, the service will be considered failed and will be shut down again. Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass "0" to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the manager configuration file, except when Type=oneshot is used, in which case the timeout is disabled by default (see systemd-system.conf(5) <http://www.freedesktop.org/software/systemd/man/systemd-system.conf.html>). If you have a lot of metadata, it might take too long to load it from disk and not reporting started status, so the daemon just gets stopped prematurely. Please take a look at diff between startup scripts: [ok][2016-02-06][04:23:58][oxide94][Ionic][~/Desktop/rpm] $ diff -ruN 2.0.81/usr/lib/systemd/system/moosefs-master.service 2.0.83/usr/lib/systemd/system/moosefs-master.service --- 2.0.81/usr/lib/systemd/system/moosefs-master.service 2015-10-30 06:49:12.000000000 +0100 +++ 2.0.83/usr/lib/systemd/system/moosefs-master.service 2016-01-08 11:05:15.000000000 +0100 @@ -10,6 +10,7 @@ ExecReload=/usr/sbin/mfsmaster reload PIDFile=/var/lib/mfs/.mfsmaster.lock TimeoutStopSec=1800 +TimeoutStartSec=1800 Restart=no [Install] [err][2016-02-06][04:24:07][oxide94][Ionic][~/Desktop/rpm] My advice is (first - make sure you have enough free space in /var/lib/mfs) to run mfsmaster -a, which creates a metadata.mfs file from last successfully saved metadata.mfs + changelogs and starts Master Server. to upgrade your Master Server to the latest stable version, 2.0.84, which resolves the issue. By the way: such behaviour will not occur if you run mfsmaster not via starting script, but just issuing a mfsmaster start command. Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 06 Feb 2016, at 1:50 AM, WK <wk...@bn...> wrote: > > got this when I restarted mfsmaster on a 2.0.76 cluster very > stock/default config > > > can't rename metadata.mfs -> metadata.mfs.back: ENOENT (No such file or > directory) > > The data seems ok, but sure enough there is not a metadata.mfs /var/lib/mfs > > Changelogs are there. > metadata.mfs.back (.1) is there. > > Should I be worried? > > -wk > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: WK <wk...@bn...> - 2016-02-06 01:17:54
|
got this when I restarted mfsmaster on a 2.0.76 cluster very stock/default config can't rename metadata.mfs -> metadata.mfs.back: ENOENT (No such file or directory) The data seems ok, but sure enough there is not a metadata.mfs /var/lib/mfs Changelogs are there. metadata.mfs.back (.1) is there. Should I be worried? -wk |
|
From: Piotr R. K. <pio...@mo...> - 2016-02-04 23:00:16
|
Hi Wolfgang,
I'd like to let you know, that since MFS 3.0.70 it is possible to mount and see old trash structure:
-o mfsflattrash use flat trash structure in meta
Best regards,
--
<https://moosefs.com/>
Piotr Robert Konopelko
MooseFS Technical Support Engineer
e-mail : pio...@mo... <mailto:pio...@mo...>
www : https://moosefs.com <https://moosefs.com/>
<https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs>
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email.
> On 15 Jan 2016, at 11:11 AM, Wolfgang <moo...@wo...> wrote:
>
> Hi!
>
> ok - many thanks for your quick answers!
>
> Keep going :-)
>
> Greetings from austria.
> -Wolfgang
>
> On 2016-01-15 11:06, Piotr Robert Konopelko wrote:
>> Hi,
>>
>>> On 15 Jan 2016, at 10:55 AM, Wolfgang < <mailto:moo...@wo...>moo...@wo... <mailto:moo...@wo...>> wrote:
>>> Yes I thought so that there are problems with lot of files in one directory - but whats the suggested way to undelete files/folders? (in big instances as well as in small instances)
>>> Probably it would be nice to have a cli-tool which can list deleted files in the folder-structure as it was - and then undelete it from client. ?
>>
>> We are thinking on rebuilding the trash and make it more comfortable to use, it is on our roadmap.
>> Unfortunately, at this moment I can't tell / guarantee when it may happen.
>>
>> Thanks for your feedback!
>>
>>
>> Best regards,
>>
>> --
>> Piotr Robert Konopelko
>> MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/>
|
84 messages has been excluded from this view by a project administrator.
