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: Michael T. <mic...@ho...> - 2018-02-15 23:24:04
|
It's me again with a different question. Through the years one of my chunkservers have gone through several disk replacements, upgrades, and additions. Disks are mounted in /mnt and named mfshdd<seq> with <seq> being a through z, ie. mfshdda, mfshddb, and so on. It started out with 3 disks, mfshdd[a-c], and now it is up to the letter i. mfshdd.cfg now looks like: /mnt/mfshdda #/mnt/mfshddb /mnt/mfshddc /mnt/mfshddd #/mnt/mfshdde /mnt/mfshddf #mnt/mfshddg #mnt/mfshddh /mnt/mfshddi I'm toying with the idea of changing a couple of the mountpoints so that I have no holes in the sequence. The steps I'm thinking of is: (a) stop moosefs-chunkserver (b) remount mfshddi as mfshddb, and mfshddf as mfshdde. (c) edit mfshdd.cfg to reflect this change (e) start moosefs-chunkserver Is this doable without losing out the chunks that are expected to be in mfshddf and mfshddi? They're still there anyway, just in a different mountpoint. Will they be recognized as valid chunks when the chunkserver is started back up and it scans the folders? --- mike t. |
|
From: Piotr R. K. <pio...@mo...> - 2018-02-15 23:23:40
|
Ok, so this is not what I thought. I suppose it could have been some network issue on Master Server Peter -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com <http://moosefs.com/> GitHub <https://github.com/moosefs/moosefs> | Twitter <https://twitter.com/moosefs> | Facebook <https://www.facebook.com/moosefs> | LinkedIn <https://www.linkedin.com/company/moosefs> > On 14 Feb 2018, at 4:57 AM, Michael Tinsay <mic...@ho...> wrote: > > The words "foreground" and "background" was *not* found in the yesterday's syslog. > > CGI says "Saved in background" > > From: Piotr Robert Konopelko <pio...@mo...> > Sent: Wednesday, February 14, 2018 5:24:50 AM > To: Michael Tinsay > Cc: MooseFS-Users > Subject: Re: [MooseFS-Users] Some glitch happened... how to troubleshoot the next time it happens? > > Hi Michael, > > could you please grep your syslog by "foreground" word or "background" word? > Or, please check on CGI, what is the status in "INFO" tab, column named "last metadata save status" - background or foreground? > > Thanks, > Peter > > -- > Piotr Robert Konopelko | mobile: +48 601 476 440 > MooseFS Client Support Team | moosefs.com <http://moosefs.com/> > > GitHub <https://github.com/moosefs/moosefs> | Twitter <https://twitter.com/moosefs> | Facebook <https://www.facebook.com/moosefs> | LinkedIn <https://www.linkedin.com/company/moosefs> > >> On 13 Feb 2018, at 10:22 AM, Michael Tinsay <mic...@ho... <mailto:mic...@ho...>> wrote: >> >> So one of my chunk servers is currently doing an internal rebalance as I had to replace a couple of disks. While monitoring its progress via the web interface, suddenly the cgi server could not see the master. After a few of frantic refreshing of the web page, the master came back up. >> >> I took a look at the syslog and saw these: >> >> Feb 13 17:00:18 HO-MFSMaster01 mfsmaster[872]: child finished >> Feb 13 17:00:18 HO-MFSMaster01 mfsmaster[872]: store process has finished - store time: 18.531 >> Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.103 / port: 9422, usedspace: 14225786048512 (13248.80 GiB), totalspace: 18739671220224 (17452.68 GiB) >> Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.101 / port: 9422, usedspace: 14516117061632 (13519.19 GiB), totalspace: 18582972526592 (17306.74 GiB) >> Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.102 / port: 9422, usedspace: 15202350829568 (14158.29 GiB), totalspace: 18827063713792 (17534.07 GiB) >> Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.110) has been closed by peer >> Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.112) has been closed by peer >> Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.111) has been closed by peer >> Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.111) has been closed by peer >> Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.99) has been closed by peer >> Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.112) has been closed by peer >> Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.103:9422,3) >> Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.103 / port: 9422, usedspace: 14225795702784 (13248.80 GiB), totalspace: 18739671220224 (17452.68 GiB) >> Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.102:9422,2) >> Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.102 / port: 9422, usedspace: 15202350829568 (14158.29 GiB), totalspace: 18827063713792 (17534.07 GiB) >> Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunk 0000000001C0B151_000000DE: there are no copies >> Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunk 0000000001C0B1B7_000000F8: there are no copies >> Feb 13 17:00:31 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.101:9422,1) >> Feb 13 17:00:31 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.101 / port: 9422, usedspace: 14516117061632 (13519.19 GiB), totalspace: 18582972526592 (17306.74 GiB) >> Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.102 / port: 9422 has been fully removed from data structures >> Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.101 / port: 9422 has been fully removed from data structures >> Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.103 / port: 9422 has been fully removed from data structures >> Feb 13 17:01:01 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.103 / port: 9422 >> Feb 13 17:01:02 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.102 / port: 9422 >> Feb 13 17:01:03 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.101 / port: 9422 >> >> No explicit error message (as far as I'm aware). Just notification that all chunkservers and clients disconnected at the same time and the chunkservers and clients reconnected around 15 seconds later. >> >> Is there a way by which I can monitor is this happens a lot? >> >> By the way, the machines are all running version 3.0.100. >> >> >> --- mike t. >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot_________________________________________ <http://sdm.link/slashdot_________________________________________> >> moosefs-users mailing list >> moo...@li... <mailto:moo...@li...> >> https://lists.sourceforge.net/lists/listinfo/moosefs-users <https://lists.sourceforge.net/lists/listinfo/moosefs-users> > > > Best regards, > Peter > > -- > Piotr Robert Konopelko | mobile: +48 601 476 440 > MooseFS Client Support Team | moosefs.com <http://moosefs.com/> > > GitHub <https://github.com/moosefs/moosefs> | Twitter <https://twitter.com/moosefs> | Facebook <https://www.facebook.com/moosefs> | LinkedIn <https://www.linkedin.com/company/moosefs> |
|
From: Michael T. <mic...@ho...> - 2018-02-15 23:14:55
|
The words "foreground" and "background" was *not* found in the yesterday's syslog. CGI says "Saved in background" ________________________________ From: Piotr Robert Konopelko <pio...@mo...> Sent: Wednesday, February 14, 2018 5:24:50 AM To: Michael Tinsay Cc: MooseFS-Users Subject: Re: [MooseFS-Users] Some glitch happened... how to troubleshoot the next time it happens? Hi Michael, could you please grep your syslog by "foreground" word or "background" word? Or, please check on CGI, what is the status in "INFO" tab, column named "last metadata save status" - background or foreground? Thanks, Peter -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com<http://moosefs.com/> GitHub<https://github.com/moosefs/moosefs> | Twitter<https://twitter.com/moosefs> | Facebook<https://www.facebook.com/moosefs> | LinkedIn<https://www.linkedin.com/company/moosefs> On 13 Feb 2018, at 10:22 AM, Michael Tinsay <mic...@ho...<mailto:mic...@ho...>> wrote: So one of my chunk servers is currently doing an internal rebalance as I had to replace a couple of disks. While monitoring its progress via the web interface, suddenly the cgi server could not see the master. After a few of frantic refreshing of the web page, the master came back up. I took a look at the syslog and saw these: Feb 13 17:00:18 HO-MFSMaster01 mfsmaster[872]: child finished Feb 13 17:00:18 HO-MFSMaster01 mfsmaster[872]: store process has finished - store time: 18.531 Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.103 / port: 9422, usedspace: 14225786048512 (13248.80 GiB), totalspace: 18739671220224 (17452.68 GiB) Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.101 / port: 9422, usedspace: 14516117061632 (13519.19 GiB), totalspace: 18582972526592 (17306.74 GiB) Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.102 / port: 9422, usedspace: 15202350829568 (14158.29 GiB), totalspace: 18827063713792 (17534.07 GiB) Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.110) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.112) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.111) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.111) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.99) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.112) has been closed by peer Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.103:9422,3) Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.103 / port: 9422, usedspace: 14225795702784 (13248.80 GiB), totalspace: 18739671220224 (17452.68 GiB) Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.102:9422,2) Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.102 / port: 9422, usedspace: 15202350829568 (14158.29 GiB), totalspace: 18827063713792 (17534.07 GiB) Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunk 0000000001C0B151_000000DE: there are no copies Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunk 0000000001C0B1B7_000000F8: there are no copies Feb 13 17:00:31 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.101:9422,1) Feb 13 17:00:31 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.101 / port: 9422, usedspace: 14516117061632 (13519.19 GiB), totalspace: 18582972526592 (17306.74 GiB) Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.102 / port: 9422 has been fully removed from data structures Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.101 / port: 9422 has been fully removed from data structures Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.103 / port: 9422 has been fully removed from data structures Feb 13 17:01:01 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.103 / port: 9422 Feb 13 17:01:02 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.102 / port: 9422 Feb 13 17:01:03 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.101 / port: 9422 No explicit error message (as far as I'm aware). Just notification that all chunkservers and clients disconnected at the same time and the chunkservers and clients reconnected around 15 seconds later. Is there a way by which I can monitor is this happens a lot? By the way, the machines are all running version 3.0.100. --- mike t. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://slashdot.org/>! http://sdm.link/slashdot_________________________________________ moosefs-users mailing list moo...@li...<mailto:moo...@li...> https://lists.sourceforge.net/lists/listinfo/moosefs-users Best regards, Peter -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com<http://moosefs.com> GitHub<https://github.com/moosefs/moosefs> | Twitter<https://twitter.com/moosefs> | Facebook<https://www.facebook.com/moosefs> | LinkedIn<https://www.linkedin.com/company/moosefs> |
|
From: Piotr R. K. <pio...@mo...> - 2018-02-13 21:25:04
|
Hi Michael, could you please grep your syslog by "foreground" word or "background" word? Or, please check on CGI, what is the status in "INFO" tab, column named "last metadata save status" - background or foreground? Thanks, Peter -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com <http://moosefs.com/> GitHub <https://github.com/moosefs/moosefs> | Twitter <https://twitter.com/moosefs> | Facebook <https://www.facebook.com/moosefs> | LinkedIn <https://www.linkedin.com/company/moosefs> > On 13 Feb 2018, at 10:22 AM, Michael Tinsay <mic...@ho... <mailto:mic...@ho...>> wrote: > > So one of my chunk servers is currently doing an internal rebalance as I had to replace a couple of disks. While monitoring its progress via the web interface, suddenly the cgi server could not see the master. After a few of frantic refreshing of the web page, the master came back up. > > I took a look at the syslog and saw these: > > Feb 13 17:00:18 HO-MFSMaster01 mfsmaster[872]: child finished > Feb 13 17:00:18 HO-MFSMaster01 mfsmaster[872]: store process has finished - store time: 18.531 > Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.103 / port: 9422, usedspace: 14225786048512 (13248.80 GiB), totalspace: 18739671220224 (17452.68 GiB) > Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.101 / port: 9422, usedspace: 14516117061632 (13519.19 GiB), totalspace: 18582972526592 (17306.74 GiB) > Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.102 / port: 9422, usedspace: 15202350829568 (14158.29 GiB), totalspace: 18827063713792 (17534.07 GiB) > Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.110) has been closed by peer > Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.112) has been closed by peer > Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.111) has been closed by peer > Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.111) has been closed by peer > Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.99) has been closed by peer > Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.112) has been closed by peer > Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.103:9422,3) > Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.103 / port: 9422, usedspace: 14225795702784 (13248.80 GiB), totalspace: 18739671220224 (17452.68 GiB) > Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.102:9422,2) > Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.102 / port: 9422, usedspace: 15202350829568 (14158.29 GiB), totalspace: 18827063713792 (17534.07 GiB) > Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunk 0000000001C0B151_000000DE: there are no copies > Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunk 0000000001C0B1B7_000000F8: there are no copies > Feb 13 17:00:31 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.101:9422,1) > Feb 13 17:00:31 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.101 / port: 9422, usedspace: 14516117061632 (13519.19 GiB), totalspace: 18582972526592 (17306.74 GiB) > Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.102 / port: 9422 has been fully removed from data structures > Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.101 / port: 9422 has been fully removed from data structures > Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.103 / port: 9422 has been fully removed from data structures > Feb 13 17:01:01 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.103 / port: 9422 > Feb 13 17:01:02 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.102 / port: 9422 > Feb 13 17:01:03 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.101 / port: 9422 > > No explicit error message (as far as I'm aware). Just notification that all chunkservers and clients disconnected at the same time and the chunkservers and clients reconnected around 15 seconds later. > > Is there a way by which I can monitor is this happens a lot? > > By the way, the machines are all running version 3.0.100. > > > --- mike t. > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot_________________________________________ <http://sdm.link/slashdot_________________________________________> > moosefs-users mailing list > moo...@li... <mailto:moo...@li...> > https://lists.sourceforge.net/lists/listinfo/moosefs-users <https://lists.sourceforge.net/lists/listinfo/moosefs-users> Best regards, Peter -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com <http://moosefs.com/> GitHub <https://github.com/moosefs/moosefs> | Twitter <https://twitter.com/moosefs> | Facebook <https://www.facebook.com/moosefs> | LinkedIn <https://www.linkedin.com/company/moosefs> |
|
From: Michael T. <mic...@ho...> - 2018-02-13 09:22:35
|
So one of my chunk servers is currently doing an internal rebalance as I had to replace a couple of disks. While monitoring its progress via the web interface, suddenly the cgi server could not see the master. After a few of frantic refreshing of the web page, the master came back up. I took a look at the syslog and saw these: Feb 13 17:00:18 HO-MFSMaster01 mfsmaster[872]: child finished Feb 13 17:00:18 HO-MFSMaster01 mfsmaster[872]: store process has finished - store time: 18.531 Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.103 / port: 9422, usedspace: 14225786048512 (13248.80 GiB), totalspace: 18739671220224 (17452.68 GiB) Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.101 / port: 9422, usedspace: 14516117061632 (13519.19 GiB), totalspace: 18582972526592 (17306.74 GiB) Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: chunkserver disconnected - ip: 10.77.77.102 / port: 9422, usedspace: 15202350829568 (14158.29 GiB), totalspace: 18827063713792 (17534.07 GiB) Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.110) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.112) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.111) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.111) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.99) has been closed by peer Feb 13 17:00:28 HO-MFSMaster01 mfsmaster[872]: connection with client(ip:10.77.77.112) has been closed by peer Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.103:9422,3) Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.103 / port: 9422, usedspace: 14225795702784 (13248.80 GiB), totalspace: 18739671220224 (17452.68 GiB) Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.102:9422,2) Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.102 / port: 9422, usedspace: 15202350829568 (14158.29 GiB), totalspace: 18827063713792 (17534.07 GiB) Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunk 0000000001C0B151_000000DE: there are no copies Feb 13 17:00:30 HO-MFSMaster01 mfsmaster[872]: chunk 0000000001C0B1B7_000000F8: there are no copies Feb 13 17:00:31 HO-MFSMaster01 mfsmaster[872]: csdb: found cs using ip:port and csid (10.77.77.101:9422,1) Feb 13 17:00:31 HO-MFSMaster01 mfsmaster[872]: chunkserver register begin (packet version: 6) - ip: 10.77.77.101 / port: 9422, usedspace: 14516117061632 (13519.19 GiB), totalspace: 18582972526592 (17306.74 GiB) Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.102 / port: 9422 has been fully removed from data structures Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.101 / port: 9422 has been fully removed from data structures Feb 13 17:00:43 HO-MFSMaster01 mfsmaster[872]: server ip: 10.77.77.103 / port: 9422 has been fully removed from data structures Feb 13 17:01:01 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.103 / port: 9422 Feb 13 17:01:02 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.102 / port: 9422 Feb 13 17:01:03 HO-MFSMaster01 mfsmaster[872]: chunkserver register end (packet version: 6) - ip: 10.77.77.101 / port: 9422 No explicit error message (as far as I'm aware). Just notification that all chunkservers and clients disconnected at the same time and the chunkservers and clients reconnected around 15 seconds later. Is there a way by which I can monitor is this happens a lot? By the way, the machines are all running version 3.0.100. --- mike t. |
|
From: Piotr R. K. <pio...@mo...> - 2018-01-29 17:13:53
|
Hi, it is nice to hear it! Thanks for following up. Best regards, Peter -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com <http://moosefs.com/> GitHub <https://github.com/moosefs/moosefs> | Twitter <https://twitter.com/moosefs> | Facebook <https://www.facebook.com/moosefs> | LinkedIn <https://www.linkedin.com/company/moosefs> > On 29 Jan 2018, at 1:07 PM, Alexander AKHOBADZE <ba...@ya...> wrote: > > > Hi! Thanks a lot! Problem seems to be fixed. > On 25.01.2018 20:48, Piotr Robert Konopelko wrote: >> Hi Alex, >> >> We have released MooseFS, so new packages of 3.0.100 are available in the repository. >> >> >> Thanks, >> >> Best regards, >> Peter >> >> -- >> Piotr Robert Konopelko | mobile: +48 601 476 440 >> MooseFS Client Support Team | moosefs.com <http://moosefs.com/> >> >> GitHub | Twitter | Facebook | LinkedIn >> >>> On 25 Jan 2018, at 8:49 AM, Alexander AKHOBADZE <ba...@ya... <mailto:ba...@ya...>> wrote: >>> >>> >>> WOW! Sounds grate! I love MooseFS! >>> >>> >>> On 25.01.2018 9:24, Jakub Kruszona-Zawadzki wrote: >>>>> On 24 Jan, 2018, at 7:36, Alexander AKHOBADZE <ba...@ya... <mailto:ba...@ya...>> wrote: >>>>> >>>>> >>>>> OK. Thanks a lot! Sorry for impatience. >>>> No problem :) >>>> >>>> We've fixed this issue. Changes are already on the github and probably today we will release this version as 3.0.100. >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot> >>> _________________________________________ >>> moosefs-users mailing list >>> moo...@li... <mailto:moo...@li...> >>> https://lists.sourceforge.net/lists/listinfo/moosefs-users <https://lists.sourceforge.net/lists/listinfo/moosefs-users> >> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Alexander A. <ba...@ya...> - 2018-01-29 11:08:09
|
Hi! Thanks a lot! Problem seems to be fixed. On 25.01.2018 20:48, Piotr Robert Konopelko wrote: > Hi Alex, > > We have released MooseFS, so new packages of 3.0.100 are available in > the repository. > > > Thanks, > > Best regards, > Peter > > -- > Piotr Robert Konopelko | mobile: +48 601 476 440 > MooseFS Client Support Team | moosefs.com <http://moosefs.com> > > GitHub | Twitter | Facebook | LinkedIn > >> On 25 Jan 2018, at 8:49 AM, Alexander AKHOBADZE <ba...@ya... >> <mailto:ba...@ya...>> wrote: >> >> >> WOW! Sounds grate! I love MooseFS! >> >> >> On 25.01.2018 9:24, Jakub Kruszona-Zawadzki wrote: >>>> On 24 Jan, 2018, at 7:36, Alexander AKHOBADZE <ba...@ya... >>>> <mailto:ba...@ya...>> wrote: >>>> >>>> >>>> OK. Thanks a lot! Sorry for impatience. >>> No problem :) >>> >>> We've fixed this issue. Changes are already on the github and >>> probably today we will release this version as 3.0.100. >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org <http://Slashdot.org>! >> http://sdm.link/slashdot >> _________________________________________ >> moosefs-users mailing list >> moo...@li... >> <mailto:moo...@li...> >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > |
|
From: Piotr R. K. <pio...@mo...> - 2018-01-25 18:10:18
|
Dear MooseFS Users, We are proud to announce, that MooseFS 3.0.100 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.100> as stable today! This version includes support of Debian 9 (Stretch) and Ubuntu 16.04 LTS, as well as many other bugfixes. If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. You can also give your valuable suggestions by opening an issue on GitHub <https://github.com/moosefs/moosefs/issues>. Thanks! Please find a complete list of changes since MooseFS 3.0.97 below: MooseFS 3.0.100-1 (2018-01-24) (cs) fixed rare segfault during chunk sending to master after disconnection (mount) added thread for cleaning released files with delay (mount) added assertion for lru cache (sustained open files) (master+mount) added chunks data cache invalidation after chunkserver disconnection and reconnection (mount) changed (lowered) number of connection retries (depends on I/O retry counter) MooseFS 3.0.99-1 (2017-11-23) (master) disconnect all clients when exports has changed (mount) do not show message about ‘negative travel time’ when the measured time is zero (happens in virtual machines) (all) fixed get16bit function on big-endian machines MooseFS 3.0.98-1 (2017-10-12) (mount) changed default cache mode on OS X from ‘direct’ to ‘auto’ due to problems with mmap (cgiserv) added seteuid to ‘mfs’ or ‘nobody’ (cs+tools) use readdir instead of readdir_r on glibc 2.24+ (debian) added support for systemd in debian packages (all) fixed library dependencies (for libpcap, libz and libm) (mount) fixed race between defered ‘open’ and ‘locks’ (master) more chunk debugs and better handling chunk status change (cs) fixed handling mark for removal (after reload sometimes cs could send chunks marked for removal as normal chunks) (master) added file with metadata checksums (for future use) (master) fixed way of sending gids to changelog/follower (master) added inode checksum for some changes sent to changelog/follower (metadump) added ‘0x’ prefix for fileds dumped as hex numbers (master) fixed ACL mask synchronization issues (restoring from changelog/leader->follower) Thank you, Best regards, Peter / MooseFS Team -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com <http://moosefs.com/> GitHub <https://github.com/moosefs/moosefs> | Twitter <https://twitter.com/moosefs> | Facebook <https://www.facebook.com/moosefs> | LinkedIn <https://www.linkedin.com/company/moosefs> > On 2 Aug 2017, at 8:08 PM, Piotr Robert Konopelko <pio...@mo...> wrote: > > Dear MooseFS Users, > > We are proud to announce, that MooseFS 3.0.97 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.97> as stable today! > This version includes bugfixes and improves stability. > > If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! > > > Please find the changes in MooseFS 3 since 3.0.94 below: > MooseFS 3.0.97-1 (2017-08-01) > (tools) fixed trash/sustained size desynchronization after file length changed by chunk creation > (mount) fixed handling invalid arguments in posix lock command > > MooseFS 3.0.96-1 (2017-07-25) > (tools) fixed segfault in mfsscadmin > > MooseFS 3.0.95-1 (2017-07-17) > (mount+master) added update master version during reconnection to master (after updating master server) > (master) fixed winattr field size in setattr command > (mount) fixed dirattrcache (freezes or inefficiences during listing directories - introduced in 3.0.93) > (cgi) fixed displaying master charts without leader (pro only) > (mount) added info about using open dir cache in oplog/ophistory > > > Best regards, > Peter / MooseFS Team > > -- > Piotr Robert Konopelko | mobile: +48 601 476 440 > MooseFS Client Support Team | moosefs.com <https://moosefs.com/> >> On 4 Jul 2017, at 8:33 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >> >> Dear MooseFS Users, >> >> We are proud to annonce, that MooseFS 3.0.94 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.94> as stable! >> This version includes bugfixes and improves stability. >> >> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! >> >> >> Please find the changes in MooseFS 3 since 3.0.91 below: >> MooseFS 3.0.94-1 (2017-06-22) >> (mount) fixed support for CREATE/REPLACE flags in setxattr >> (mount) added headers for flock defines >> (all) added check for poll.h header file and use it instead of sys/poll.h if possible >> (master) added test for WRITE access on directory during moving between different parents >> (master) added clearing suig/sgid during write >> (master+mount) increased max symlink path size to 4096(posix compliance) >> >> MooseFS 3.0.93-1 (2017-06-01) >> (master) redesigned xattr storage (much faster and uses less memory) >> (master) improved hash map in xattr and acl (static -> dynamic) >> (cgi+cli) added possibility to define master group as set of IP adresses divided by comma or semicolon >> (cs) fixed using fsync on closed descriptors (after change FSYNC_BEFORE_CLOSE option) >> (master) fixed removing default acl >> (master+mount) added support for basic Windows attributes (hidden, ro, system, archive) >> (cgi+cli) fixed working with followers only >> (all) added api for reading config parameters from master and chunkserver >> (tools) increased timeout from 10 seconds to 20 seconds (needed for huge snapshots) >> >> MooseFS 3.0.92-1 (2017-04-27) >> (master+tools) added chunk slices to mfsappendchunks >> (tools) added archive mode tools >> (master+mount) fixed getfacl (unnecessary check for read rights for uid/gid) >> (master) fixed changing acl mask during setattr >> >> >> Best regards, >> Peter / MooseFS Team >> >> -- >> Piotr Robert Konopelko | mobile: +48 601 476 440 >> MooseFS Client Support Team | moosefs.com <https://moosefs.com/> >>> On 10 Apr 2017, at 6:04 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>> >>> Dear MooseFS Users, >>> >>> We are proud to annonce, that MooseFS 3.0.91 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.88> as stable! >>> This version includes bugfixes and improves stability. >>> >>> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! >>> >>> >>> Please find the changes in MooseFS 3 since 3.0.88 below: >>> MooseFS 3.0.91-1 (2017-04-07) >>> (all) silence false warnings generated by static analyzers (clang and cppcheck) >>> (master) fixed quota testing routine used during move/rename >>> (all) added README.md to distribution >>> (cs+mount) decreased delay in conncache >>> (mount) fixed reading done by many (20+) threads using one descriptor (premature removing requests from queue during cleaning) >>> >>> MooseFS 3.0.90-1 (2017-03-15) >>> (master) fixed move/rename with quota >>> (master) fixed chunk counters shown in cli/cgi >>> (master+tools) added option preserve hardlinks to mfsmakesnapshot >>> (master) fixed acl copying during mfsmakesnapshot >>> >>> MooseFS 3.0.89-1 (2017-02-21) >>> (mount) added fixing file length in all inodes after write >>> (cs) split bitfiled into separate bytes (fixed potential race condition) >>> (master) setting operation to NONE before sending status (silence unnecessary messages in some cases) >>> (cs) increased verbosity of crc-error messages >>> (cs) fixed invalidating preserved block in case of truncate down followed by truncate up >>> (mount) increased master-proxy buffer sizes >>> >>> >>> >>> Best regards, >>> Peter / MooseFS Team >>> >>> -- >>> Piotr Robert Konopelko >>> MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> >>>> On 9 Feb 2017, at 3:12 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>> >>>> Dear MooseFS Users, >>>> >>>> We are proud to annonce, that MooseFS 3.0.88 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.88> as stable today! >>>> This version includes bugfixes and improves stability (mainly concerning MooseFS Client). >>>> >>>> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! >>>> >>>> >>>> Please find the changes in MooseFS 3 since 3.0.86 below: >>>> MooseFS 3.0.88-1 (2017-02-08) >>>> (mount) added read cache clean on write (same file access using different descriptors) >>>> (mount) added missing cond_destroy in readdata.c (fix sent by Jakub Ratajczak) >>>> (master) fixed initializing packet size for reading 'sustained' directory >>>> (all) fixed zassert for printing correct statuses in case of pthread functions >>>> >>>> MooseFS 3.0.87-1 (2017-02-01) >>>> (mount) fix fleng in finfo after truncate (patched by Davies Liu) >>>> (mount) fix overlapped read (patched by Davies Liu) >>>> (mount) fixed invalidating chunk cache after truncate >>>> (mount) fixed fleng handling in read worker >>>> (mount) fixed handling BREAK state in read worker >>>> (mount) changed handling data invalidation in read module (sometimes could be less efficient, but it is much more safer) >>>> (tools) fixed number parsing (patched by Pawel Gawronski) >>>> (cli) fixed printed host/port options >>>> (mount) moved pipes from requests to workers (read and write - huge decrease of descriptors used by mount) >>>> (mount) changed signal to broadcast in rwlock (fixed very rare read/write deadlock) >>>> (mount) fixed 'open descriptors' leak (lookup(with data for open)->open(with cached data)->close) >>>> (mount) fixed potential 'race condition' - free csdata during access >>>> (master) split (only internally) sustained folder into 256 subfolders (too many sustained files caused socket timeouts in master) >>>> >>>> >>>> Best regards, >>>> Peter / MooseFS Team >>>> >>>> -- >>>> Piotr Robert Konopelko >>>> MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> >>>>> On 02 Dec 2016, at 7:54 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>>> >>>>> Dear MooseFS Users, >>>>> >>>>> we released the newest version MooseFS 3.0 recently: MooseFS 3.0.86. >>>>> This version mainly contains bugfixes and improves stability. >>>>> >>>>> >>>>> We strongly recommend to upgrade to the latest version, but please remember, that If you had version lower than 3.0.83 and then you upgraded your Chunkservers to v. 3.0.83 or higher, please DO NOT downgrade them! >>>>> In MooseFS Chunkserver v. 3.0.83 we changed Chunk header from 5k to 8k (see changelog) - this is one of major changes and it means, that Chunkserver older than 3.0.83 cannot "understand" new Chunk header, which may lead to potential data loss! >>>>> >>>>> >>>>> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Thanks! >>>>> >>>>> >>>>> Please find the changes in MooseFS 3 since 3.0.77 below: >>>>> MooseFS 3.0.86-1 (2016-11-30) >>>>> (master) fixed leader-follower resynchronization after reconnection (pro only) >>>>> (master) fixed rehashing condition in edge/node/chunk hashmaps (change inspired by yinjiawind) >>>>> >>>>> MooseFS 3.0.85-1 (2016-11-17) >>>>> (mount) fixed memory leak (also efficiency) on Linux and potential segfaults on FreeBSD (negative condition) >>>>> (mount) fixed race condition for inode value in write module >>>>> (mount) better descriptors handling (lists of free elements) >>>>> (mount) better releasing descriptors on FreeBSD >>>>> (cs) fixed time condition (patch send by yinjiawind) >>>>> >>>>> MooseFS 3.0.84-1 (2016-10-06) >>>>> (master) fixed setting acl-default without named users or named groups >>>>> (master) fixed master-follower synchronization after setting storage class >>>>> >>>>> MooseFS 3.0.83-1 (2016-09-30) >>>>> (cs) changed header size from 5k to 8k (due to 4k-sector hard disks) >>>>> >>>>> MooseFS 3.0.82-1 (2016-09-28) >>>>> (all) silenced message about using deprecated parameter 'oom_adj' >>>>> (mount) fixed FreeBSD delayed release mechanism >>>>> (mount) added rwlock for chunks >>>>> >>>>> MooseFS 3.0.81-1 (2016-07-25) >>>>> (mount) fixed oom killer disabling (setting oom_adj and oom_score_adj) >>>>> (cli) fixed displaying inactive mounts >>>>> (mount) added fsync before removing any locks >>>>> (daemons) added disabling oom killer (Linux only) >>>>> (all) small fixes in manpages >>>>> (mount) fixed handling nonblocking lock commands (unlock and try) in both locking mechanisms >>>>> (daemons+mount) changed default settings for limiting malloc arenas (Linux only) >>>>> >>>>> MooseFS 3.0.80-1 (2016-07-13) >>>>> (master) fixed chunk loop (in some cases chunks from the last hash position might be left unchecked) >>>>> (master) fixed storage class management (fixed has_***_labels fields) >>>>> >>>>> MooseFS 3.0.79-1 (2016-07-05) >>>>> (master) fixed 'flock' (change type of lock SH->EX and EX->SH caused access to freed memory and usually SEGV) >>>>> >>>>> MooseFS 3.0.78-1 (2016-06-14) >>>>> (cs) fixed serious error that may cause data corruption during internal rebalance (intr. in 3.0.75) >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> Peter >>>>> >>>>> -- >>>>> >>>>> <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 08 Jun 2016, at 1:04 AM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>>>> >>>>>> Dear MooseFS Users, >>>>>> >>>>>> we released the newest versions of both MooseFS 3.0 and MooseFS 2.0 recently: 3.0.77 and 2.0.89. >>>>>> >>>>>> They improve MooseFS stability and (in MooseFS 3.0) also add new features, like: >>>>>> Storage Classes <https://moosefs.com/documentation/moosefs-3-0.html> >>>>>> Possibility to mount MooseFS on Linux by issuing: mount -t moosefs mfsmaster.example.lan: /mnt/mfs >>>>>> File sparsification >>>>>> Automatic temporary maintenance mode >>>>>> New I/O synchronisation between different mounts >>>>>> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Thanks! >>>>>> >>>>>> >>>>>> Please find the changes in MooseFS 3 since 3.0.73 below: >>>>>> MooseFS 3.0.77-1 (2016-06-07) >>>>>> (mount) added assertions after packet allocation in master communication module >>>>>> (manpages) fixes related to storage classes >>>>>> (all) improved error messages used for storage classes >>>>>> >>>>>> MooseFS 3.0.76-1 (2016-06-03) >>>>>> (master) fixed resolving multi path for root inode >>>>>> (master) fixed licence expiration behaviour (pro only) >>>>>> >>>>>> MooseFS 3.0.75-1 (2016-04-20) >>>>>> (all) fixed cppcheck warnings/errors (mostly false negatives) >>>>>> (cs) added file sparsification during chunk write (also chunk replication, chunk duplication etc.) >>>>>> (mount) fixed write data inefficiency when I/O was performed by root >>>>>> (master) fixed removing too early locked chunks from data structures >>>>>> (tools) fixed reusing local ports (connection to master returned EADDRNOTAVAIL) >>>>>> (all) changed default action from restart to start >>>>>> (all) added exiting when user defined config (option -c) cannot be loaded >>>>>> (cs) changed handling chunk filename (dynamic filename generation - cs should use less memory) >>>>>> (netdump) changed 'moose ports only' option to 'port range' >>>>>> (mount) limited number of files kept as open after close >>>>>> (cs) changed subfolder choosing algorithm >>>>>> (mount) changed mutex lock to rw-lock for I/O on the same descriptor >>>>>> (mount) added link to mfsmount from '/sbin/mount.moosefs' (Linux only) >>>>>> (all) introduced "storage classes" (new goal/labels management) >>>>>> (master+cs) introduced 'temporary maintenance mode' (automatic maintenance mode after graceful stop of cs) >>>>>> (master+mount) added fix for bug in FreeBSD kernel (kernel sends truncate before first close - FreeBSD only) >>>>>> (cs) fixed setting malloc pools on Linux >>>>>> >>>>>> MooseFS 3.0.74-1 (2016-03-08) >>>>>> (master) fixed rebalance replication (check for all chunk copies for destination - not only valid) >>>>>> (master+mount) new mechanism for atime+mtime setting during I/O >>>>>> (master+mount) new I/O synchronization between different mounts (with cache invalidation) >>>>>> (master+mount) new chunk number/version cache (with automatic invalidation from master) >>>>>> (master) added mapping chunkserver IP classes (allow to have separate network for I/O and separate for other activity) >>>>>> (master) fixed status returned by writechunk after network down/up >>>>>> (master) changed trashtime from seconds to hours >>>>>> (master) added METADATA_SAVE_FREQ option (allow to save metadata less frequently than every hour) >>>>>> (master) added using in emergency (endangered chunks) all available servers for replication (even overloaded and being maintained) >>>>>> (master) added using chunkservers in 'internal rebalance' state in case of deleting chunks >>>>>> (all) spell check errors fixed (patch contributed by Dmitry Smirnov) >>>>>> >>>>>> Please find the changes in MooseFS 2.0 since 2.0.88 below: >>>>>> MooseFS 2.0.89-1 (2016-04-27) >>>>>> (master+mount) added fix for bug in FreeBSD kernel (kernel sends truncate before first close - FreeBSD only) >>>>>> >>>>>> 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 08 Mar 2016, at 9:24 AM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>>>>> >>>>>>> Dear MooseFS Users, >>>>>>> >>>>>>> we released the newest versions of both MooseFS 3 and MooseFS 2 recently: 3.0.73 and 2.0.88. >>>>>>> >>>>>>> Please find the changes in MooseFS 3 since 3.0.71 below: >>>>>>> >>>>>>> MooseFS 3.0.73-1 (2016-02-11) >>>>>>> (master) fixed restoring ARCHCHG from changelog >>>>>>> (cli+cgi) fixed displaying master list with followers only (pro version only) >>>>>>> (master) added using size and length quota to fix disk usage values (statfs) >>>>>>> (master) fixed xattr bug which may lead to data corruption and segfaults (intr. in 2.1.1) >>>>>>> (master) added 'node_info' packet >>>>>>> (tools) added '-p' option to 'mfsdirinfo' - 'precise mode' >>>>>>> (master) fixed edge renumeration >>>>>>> (master) added detecting of wrong edge numbers and force renumeration in such case >>>>>>> >>>>>>> MooseFS 3.0.72-1 (2016-02-04) >>>>>>> (master+cgi+cli) added global 'umask' option to exports.cfg >>>>>>> (all) changed address of FSF in GPL licence text >>>>>>> (debian) removed obsolete conffiles >>>>>>> (debian) fixed copyright file >>>>>>> (mount) fixed parsing mfsmount.cfg (system options like nodev,noexec etc. were ommited) >>>>>>> (master) changed way how cs internal rebalance state is treated by master (as 'grace' state instead of 'overloaded') >>>>>>> (mount) fixed bug in read module (setting etab after ranges realloc) >>>>>>> (tools) removed obsoleted command 'mfssnapshot' >>>>>>> >>>>>>> >>>>>>> Please find the changes in MooseFS 2 since 2.0.83 below: >>>>>>> >>>>>>> MooseFS 2.0.88-1 (2016-03-02) >>>>>>> (master) added METADATA_SAVE_FREQ option (allow to save metadata less frequently than every hour) >>>>>>> >>>>>>> MooseFS 2.0.87-1 (2016-02-23) >>>>>>> (master) fixed status returned by writechunk after network down/up >>>>>>> >>>>>>> MooseFS 2.0.86-1 (2016-02-22) >>>>>>> (master) fixed initialization of ATIME_MODE >>>>>>> >>>>>>> MooseFS 2.0.85-1 (2016-02-11) >>>>>>> (master) added ATIME_MODE option to set atime modification behaviour >>>>>>> (master) added using size and length quota to fix disk usage values (statfs) >>>>>>> (all) changed address of FSF in GPL licence text >>>>>>> (debian) removed obsolete conffiles >>>>>>> (debian) fixed copyright file >>>>>>> (mount) fixed parsing mfsmount.cfg (system options like nodev,noexec etc. were ommited) >>>>>>> (tools) removed obsoleted command 'mfssnapshot' >>>>>>> >>>>>>> MooseFS 2.0.84-1 (2016-01-19) >>>>>>> (mount) fixed setting file length in write module during truncate (fixes "git svn" case) >>>>>>> >>>>>>> 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 27 Jan 2016, at 5:51 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>>>>>> >>>>>>>> Dear MooseFS Users, >>>>>>>> >>>>>>>> today we published the newest version from 3.x branch: 3.0.71. >>>>>>>> >>>>>>>> Please find the changes since 3.0.69 below: >>>>>>>> >>>>>>>> MooseFS 3.0.71-1 (2016-01-21) >>>>>>>> (master) fixed emptying trash issue (intr. in 3.0.64) >>>>>>>> (master) fixed possible segfault in chunkservers database (intr. in 3.0.67) >>>>>>>> (master) changed trash part choice from nondeterministic to deterministic >>>>>>>> >>>>>>>> MooseFS 3.0.70-1 (2016-01-19) >>>>>>>> (cgi+cli) fixed displaying info when there are no active masters (intr. in 3.0.67) >>>>>>>> (mount+common) refactoring code to be Windows ready >>>>>>>> (mount) added option 'mfsflattrash' (makes trash look like before version 3.0.64) >>>>>>>> (mount) added fixes for NetBSD (patch contributed by Tom Ivar Helbekkmo) >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> -- >>>>>>>> Piotr Robert Konopelko >>>>>>>> MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
|
From: Piotr R. K. <pio...@mo...> - 2018-01-25 17:49:05
|
Hi Alex, We have released MooseFS, so new packages of 3.0.100 are available in the repository. Thanks, Best regards, Peter -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com GitHub | Twitter | Facebook | LinkedIn > On 25 Jan 2018, at 8:49 AM, Alexander AKHOBADZE <ba...@ya...> wrote: > > > WOW! Sounds grate! I love MooseFS! > > > On 25.01.2018 9:24, Jakub Kruszona-Zawadzki wrote: >>> On 24 Jan, 2018, at 7:36, Alexander AKHOBADZE <ba...@ya...> wrote: >>> >>> >>> OK. Thanks a lot! Sorry for impatience. >> No problem :) >> >> We've fixed this issue. Changes are already on the github and probably today we will release this version as 3.0.100. >> >> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Alexander A. <ba...@ya...> - 2018-01-25 07:49:36
|
WOW! Sounds grate! I love MooseFS! On 25.01.2018 9:24, Jakub Kruszona-Zawadzki wrote: >> On 24 Jan, 2018, at 7:36, Alexander AKHOBADZE <ba...@ya...> wrote: >> >> >> OK. Thanks a lot! Sorry for impatience. > No problem :) > > We've fixed this issue. Changes are already on the github and probably today we will release this version as 3.0.100. > > |
|
From: Jakub Kruszona-Z. <jak...@ge...> - 2018-01-25 06:25:06
|
> On 24 Jan, 2018, at 7:36, Alexander AKHOBADZE <ba...@ya...> wrote: > > > OK. Thanks a lot! Sorry for impatience. No problem :) We've fixed this issue. Changes are already on the github and probably today we will release this version as 3.0.100. -- Regards, Jakub Kruszona-Zawadzki - - - - - - - - - - - - - - - - Segmentation fault (core dumped) Phone: +48 602 212 039 |
|
From: Jakub Kruszona-Z. <jak...@ge...> - 2018-01-24 06:45:14
|
> On 24 Jan, 2018, at 7:16, Alexander AKHOBADZE <ba...@ya...> wrote: > > Hi again! > > No solutions? It's a pity ... :--( Is the MooseFS alive? Yes it is. We are working on that. I usually want to reproduce error and find solution before writing anything. In my opinion chunksdata cache in mount is the source of this behaviour. We will add mechanism of invalidation this cache on chunkserver disconnection. We'll also short timeouts in mfsmount during first connection and quicker cache invalidation by mount itself. We will let you know. > > Alexander > > >> Hi guys! >> >> I have a very strange situation (in my opinion). >> >> I am building a new Moose cluster. By now I have just 2 chunk servers. >> >> So when one of them is offline MFS client still tryes to connect to it! >> >> I see it using tcpdump running on MFS client. >> >> It is strange because MFS master knows about offline chunk server (shown as "Disconnected Chunk Servers" on Web-CGI page) >> >> and it is surprise for my why master points client to the dead chunk server. >> >> So because of such attempts I have a HUGE !!!!!!! performance degradation and it stops me from running MooseFS in production. >> >> It there any workaround or fix? Many thanks! >> >> My environment: >> >> MFS version: 3.0.99 >> >> Master OS: >> >> # uname -a >> FreeBSD mfs-master-1 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017 ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 >> >> Chunk server and client OS: >> >> # uname -a >> Linux proxmox-2 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 12:36:49 +0100) x86_64 GNU/Linux >> # cat /etc/debian_version >> 9.3 >> >> wbr >> >> Alexander >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users -- Regards, Jakub Kruszona-Zawadzki - - - - - - - - - - - - - - - - Segmentation fault (core dumped) Phone: +48 602 212 039 |
|
From: Alexander A. <ba...@ya...> - 2018-01-24 06:36:44
|
OK. Thanks a lot! Sorry for impatience. On 24.01.2018 9:26, Jakub Kruszona-Zawadzki wrote: >> On 24 Jan, 2018, at 7:16, Alexander AKHOBADZE <ba...@ya...> wrote: >> >> Hi again! >> >> No solutions? It's a pity ... :--( Is the MooseFS alive? > Yes it is. > > We are working on that. > > I usually want to reproduce error and find solution before writing anything. > > In my opinion chunksdata cache in mount is the source of this behaviour. We will add mechanism of invalidation this cache on chunkserver disconnection. We'll also short timeouts in mfsmount during first connection and quicker cache invalidation by mount itself. We will let you know. > >> Alexander >> >> >>> Hi guys! >>> >>> I have a very strange situation (in my opinion). >>> >>> I am building a new Moose cluster. By now I have just 2 chunk servers. >>> >>> So when one of them is offline MFS client still tryes to connect to it! >>> >>> I see it using tcpdump running on MFS client. >>> >>> It is strange because MFS master knows about offline chunk server (shown as "Disconnected Chunk Servers" on Web-CGI page) >>> >>> and it is surprise for my why master points client to the dead chunk server. >>> >>> So because of such attempts I have a HUGE !!!!!!! performance degradation and it stops me from running MooseFS in production. >>> >>> It there any workaround or fix? Many thanks! >>> >>> My environment: >>> >>> MFS version: 3.0.99 >>> >>> Master OS: >>> >>> # uname -a >>> FreeBSD mfs-master-1 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017 ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> Chunk server and client OS: >>> >>> # uname -a >>> Linux proxmox-2 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 12:36:49 +0100) x86_64 GNU/Linux >>> # cat /etc/debian_version >>> 9.3 >>> >>> wbr >>> >>> Alexander >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _________________________________________ >>> moosefs-users mailing list >>> moo...@li... >>> https://lists.sourceforge.net/lists/listinfo/moosefs-users >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Aleksander W. <ale...@mo...> - 2018-01-24 06:23:35
|
Hi. MooseFS alive! Thank you for all this information. I would like to add that we are debugging our code right now. When we release new version we will inform you. Please observe our github page for new commits. https://github.com/moosefs/moosefs Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com On 24.01.2018 07:16, Alexander AKHOBADZE wrote: > Hi again! > > No solutions? It's a pity ... :--( Is the MooseFS alive? > > Alexander > > >> Hi guys! >> >> I have a very strange situation (in my opinion). >> >> I am building a new Moose cluster. By now I have just 2 chunk servers. >> >> So when one of them is offline MFS client still tryes to connect to it! >> >> I see it using tcpdump running on MFS client. >> >> It is strange because MFS master knows about offline chunk server >> (shown as "Disconnected Chunk Servers" on Web-CGI page) >> >> and it is surprise for my why master points client to the dead chunk >> server. >> >> So because of such attempts I have a HUGE !!!!!!! performance >> degradation and it stops me from running MooseFS in production. >> >> It there any workaround or fix? Many thanks! >> >> My environment: >> >> MFS version: 3.0.99 >> >> Master OS: >> >> # uname -a >> FreeBSD mfs-master-1 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue >> Nov 14 06:12:40 UTC 2017 >> ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 >> >> Chunk server and client OS: >> >> # uname -a >> Linux proxmox-2 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 >> 12:36:49 +0100) x86_64 GNU/Linux >> # cat /etc/debian_version >> 9.3 >> >> wbr >> >> Alexander >> >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Alexander A. <ba...@ya...> - 2018-01-24 06:16:22
|
Hi again! No solutions? It's a pity ... :--( Is the MooseFS alive? Alexander > Hi guys! > > I have a very strange situation (in my opinion). > > I am building a new Moose cluster. By now I have just 2 chunk servers. > > So when one of them is offline MFS client still tryes to connect to it! > > I see it using tcpdump running on MFS client. > > It is strange because MFS master knows about offline chunk server > (shown as "Disconnected Chunk Servers" on Web-CGI page) > > and it is surprise for my why master points client to the dead chunk > server. > > So because of such attempts I have a HUGE !!!!!!! performance > degradation and it stops me from running MooseFS in production. > > It there any workaround or fix? Many thanks! > > My environment: > > MFS version: 3.0.99 > > Master OS: > > # uname -a > FreeBSD mfs-master-1 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue > Nov 14 06:12:40 UTC 2017 > ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 > > Chunk server and client OS: > > # uname -a > Linux proxmox-2 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 > 12:36:49 +0100) x86_64 GNU/Linux > # cat /etc/debian_version > 9.3 > > wbr > > Alexander > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Alexander A. <ba...@ya...> - 2018-01-23 07:42:32
|
Hi guys! I have a very strange situation (in my opinion). I am building a new Moose cluster. By now I have just 2 chunk servers. So when one of them is offline MFS client still tryes to connect to it! I see it using tcpdump running on MFS client. It is strange because MFS master knows about offline chunk server (shown as "Disconnected Chunk Servers" on Web-CGI page) and it is surprise for my why master points client to the dead chunk server. So because of such attempts I have a HUGE !!!!!!! performance degradation and it stops me from running MooseFS in production. It there any workaround or fix? Many thanks! My environment: MFS version: 3.0.99 Master OS: # uname -a FreeBSD mfs-master-1 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017 ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 Chunk server and client OS: # uname -a Linux proxmox-2 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 12:36:49 +0100) x86_64 GNU/Linux # cat /etc/debian_version 9.3 wbr Alexander |
|
From: Grouchy S. <sys...@gr...> - 2018-01-05 09:22:13
|
Hello, It's normal to have that many open files. The mount points are being used by Nginx and uWSGI servers to process website data. Current highest: 39901 Current lowest: 20190 FreeBSD is at version 11.1 across all servers. On 01/05/2018 12:48 AM, Aleksander Wieliczko wrote: > Hi, > I would like to ask you about number of open files. > Is it normal state, that this specific client has so many open files? > Can you check it? > > Would you be so kind and tell us what is your FreeBSD version? > > Best regards > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <moosefs.com> > > On 04.01.2018 15:28, Grouchy Sysadmin wrote: >> >> As of right now, there are 207129 open files on the busiest mount point. >> >> However, the error is not currently happening. The last 'packet too >> long' error happened about five hours ago. >> >> Thank you >> >> >> On 01/03/2018 11:16 PM, Aleksander Wieliczko wrote: >>> Hi, >>> I would like to say that we are checking the source of the problem. >>> Can you tell us how many open files are displayed on MooseFS CGI web >>> page on the "Mount" tab? >>> I mean the highest number of open files. >>> >>> Best regards >>> Aleksander Wieliczko >>> Technical Support Engineer >>> MooseFS.com <moosefs.com> >>> >>> On 22.12.2017 15:38, Grouchy Sysadmin wrote: >>>> We're seeing lots of these entries in the logs on the master server. >>>> >>>> Dec 22 14:30:18 mfs_master mfsmaster[59865]: main master server >>>> module: packet too long (1246408/1000000) >>>> Dec 22 14:31:19 mfs_master mfsmaster[59865]: main master server >>>> module: packet too long (1244756/1000000) >>>> Dec 22 14:32:20 mfs_master mfsmaster[59865]: main master server >>>> module: packet too long (1243948/1000000) >>>> >>>> MooseFS version is 3.0.99 from the FreeBSD ports tree. Are these >>>> entries something to be concerned about? >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _________________________________________ >>>> moosefs-users mailing list >>>> moo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/moosefs-users >>> >> > |
|
From: Aleksander W. <ale...@mo...> - 2018-01-05 06:49:11
|
Hi, I would like to ask you about number of open files. Is it normal state, that this specific client has so many open files? Can you check it? Would you be so kind and tell us what is your FreeBSD version? Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 04.01.2018 15:28, Grouchy Sysadmin wrote: > > As of right now, there are 207129 open files on the busiest mount point. > > However, the error is not currently happening. The last 'packet too > long' error happened about five hours ago. > > Thank you > > > On 01/03/2018 11:16 PM, Aleksander Wieliczko wrote: >> Hi, >> I would like to say that we are checking the source of the problem. >> Can you tell us how many open files are displayed on MooseFS CGI web >> page on the "Mount" tab? >> I mean the highest number of open files. >> >> Best regards >> Aleksander Wieliczko >> Technical Support Engineer >> MooseFS.com <moosefs.com> >> >> On 22.12.2017 15:38, Grouchy Sysadmin wrote: >>> We're seeing lots of these entries in the logs on the master server. >>> >>> Dec 22 14:30:18 mfs_master mfsmaster[59865]: main master server >>> module: packet too long (1246408/1000000) >>> Dec 22 14:31:19 mfs_master mfsmaster[59865]: main master server >>> module: packet too long (1244756/1000000) >>> Dec 22 14:32:20 mfs_master mfsmaster[59865]: main master server >>> module: packet too long (1243948/1000000) >>> >>> MooseFS version is 3.0.99 from the FreeBSD ports tree. Are these >>> entries something to be concerned about? >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _________________________________________ >>> moosefs-users mailing list >>> moo...@li... >>> https://lists.sourceforge.net/lists/listinfo/moosefs-users >> > |
|
From: Grouchy S. <sys...@gr...> - 2018-01-04 14:28:28
|
As of right now, there are 207129 open files on the busiest mount point. However, the error is not currently happening. The last 'packet too long' error happened about five hours ago. Thank you On 01/03/2018 11:16 PM, Aleksander Wieliczko wrote: > Hi, > I would like to say that we are checking the source of the problem. > Can you tell us how many open files are displayed on MooseFS CGI web > page on the "Mount" tab? > I mean the highest number of open files. > > Best regards > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <moosefs.com> > > On 22.12.2017 15:38, Grouchy Sysadmin wrote: >> We're seeing lots of these entries in the logs on the master server. >> >> Dec 22 14:30:18 mfs_master mfsmaster[59865]: main master server >> module: packet too long (1246408/1000000) >> Dec 22 14:31:19 mfs_master mfsmaster[59865]: main master server >> module: packet too long (1244756/1000000) >> Dec 22 14:32:20 mfs_master mfsmaster[59865]: main master server >> module: packet too long (1243948/1000000) >> >> MooseFS version is 3.0.99 from the FreeBSD ports tree. Are these >> entries something to be concerned about? >> >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > |
|
From: Aleksander W. <ale...@mo...> - 2018-01-04 05:16:45
|
Hi, I would like to say that we are checking the source of the problem. Can you tell us how many open files are displayed on MooseFS CGI web page on the "Mount" tab? I mean the highest number of open files. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 22.12.2017 15:38, Grouchy Sysadmin wrote: > We're seeing lots of these entries in the logs on the master server. > > Dec 22 14:30:18 mfs_master mfsmaster[59865]: main master server > module: packet too long (1246408/1000000) > Dec 22 14:31:19 mfs_master mfsmaster[59865]: main master server > module: packet too long (1244756/1000000) > Dec 22 14:32:20 mfs_master mfsmaster[59865]: main master server > module: packet too long (1243948/1000000) > > MooseFS version is 3.0.99 from the FreeBSD ports tree. Are these > entries something to be concerned about? > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Grouchy S. <sys...@gr...> - 2017-12-22 14:54:03
|
We're seeing lots of these entries in the logs on the master server. Dec 22 14:30:18 mfs_master mfsmaster[59865]: main master server module: packet too long (1246408/1000000) Dec 22 14:31:19 mfs_master mfsmaster[59865]: main master server module: packet too long (1244756/1000000) Dec 22 14:32:20 mfs_master mfsmaster[59865]: main master server module: packet too long (1243948/1000000) MooseFS version is 3.0.99 from the FreeBSD ports tree. Are these entries something to be concerned about? |
|
From: <ba...@na...> - 2017-12-16 20:44:44
|
Hi! Thanks for reply!
Sorry for my bad English.
I meant than there is no file in dir figured in DATA_PATH containing metadata on metalogger host.
As I see on CGI page, master thinks that metalogger is connected.
But metalogger itself can't download metadata ("download start error" in log).
No FW is configured on there hosts (master and metalogger).
And after master daemon restart "download start error" disappears.
wbr
Alexander.
======================================================================
> Hi Alex,
> "DATA_PATH" variable needs to be set in /etc/mfs/mfsmetalogger.cfg
> file, because in DATA_PATH directory all the changelogs and metadata files are kept.
> Default value is /var/lib/mfs, you can set DATA_PATH to this value.
> Secondly, please check if you have port 9419 opened.
> Thanks,
> Best regards,
> Peter
|
|
From: Piotr R. K. <pio...@mo...> - 2017-12-15 19:04:57
|
Hi Alex, "DATA_PATH" variable needs to be set in /etc/mfs/mfsmetalogger.cfg file, because in DATA_PATH directory all the changelogs and metadata files are kept. Default value is /var/lib/mfs, you can set DATA_PATH to this value. Secondly, please check if you have port 9419 opened. Thanks, Best regards, Peter -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com GitHub | Twitter | Facebook | LinkedIn > On 14 Dec 2017, at 5:32 PM, ba...@na... wrote: > > > Hi again! > No suggestions? > > In addition I have to inform that download error solves after I restart master daemon. > > wbr > Alexander. > > ====================================================================== > >> Hi All! > >> I have a trouble on metalogger. > >> There is an error in log: > >> Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: open files limit has >> been set to: 4096 >> Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: set gid to 925 >> Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: set uid to 925 >> Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: monotonic clock >> function: clock_gettime >> Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: monotonic clock >> speed: 254168 ops / 10 mili seconds >> Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: connecting ... >> Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: connected to Master >> Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: download start error >> Dec 13 13:10:30 mfs-master-1 mfsmetalogger[64016]: download start error > >> and DATA_PATH is empty. > >> But at the same time Web CGI page shows that this metalogger is >> connected to master. > >> Please help to fix. > >> My environment: > >> Moose version 3.0.97 > >> OS on master and metalogger > >> # uname -a >> FreeBSD mfs-master-2 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov >> 14 06:12:40 UTC 2017 >> ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: <ba...@na...> - 2017-12-14 16:48:23
|
Hi again! No suggestions? In addition I have to inform that download error solves after I restart master daemon. wbr Alexander. ====================================================================== > Hi All! > I have a trouble on metalogger. > There is an error in log: > Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: open files limit has > been set to: 4096 > Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: set gid to 925 > Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: set uid to 925 > Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: monotonic clock > function: clock_gettime > Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: monotonic clock > speed: 254168 ops / 10 mili seconds > Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: connecting ... > Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: connected to Master > Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: download start error > Dec 13 13:10:30 mfs-master-1 mfsmetalogger[64016]: download start error > and DATA_PATH is empty. > But at the same time Web CGI page shows that this metalogger is > connected to master. > Please help to fix. > My environment: > Moose version 3.0.97 > OS on master and metalogger > # uname -a > FreeBSD mfs-master-2 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov > 14 06:12:40 UTC 2017 > ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 |
|
From: Alexander A. <ba...@ya...> - 2017-12-13 10:20:33
|
Hi All! I have a trouble on metalogger. There is an error in log: Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: open files limit has been set to: 4096 Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: set gid to 925 Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: set uid to 925 Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: monotonic clock function: clock_gettime Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: monotonic clock speed: 254168 ops / 10 mili seconds Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: connecting ... Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: connected to Master Dec 13 13:02:02 mfs-master-1 mfsmetalogger[64016]: download start error Dec 13 13:10:30 mfs-master-1 mfsmetalogger[64016]: download start error and DATA_PATH is empty. But at the same time Web CGI page shows that this metalogger is connected to master. Please help to fix. My environment: Moose version 3.0.97 OS on master and metalogger # uname -a FreeBSD mfs-master-2 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017 ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 |
84 messages has been excluded from this view by a project administrator.
