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: Wolfgang <moo...@wo...> - 2017-02-16 23:00:24
|
Hi! I'm running Moosesfs 3.0.86 on Ubuntu 14.04 master and chunkservers, metaloggers and would like to upgrade to 3.0.88 In the documentation I found following order to upgrade: 1. master 2. cigserv 3. metaloggers (one-by-one) 4. chunkservers (one-by-one) 5. mfs-clients (one-by-one) In my case I can allow my cluster a downtime So I could stop all mfs processes (master,chunkserver,metaloggers) and do an aptitude update aptitude safe-upgrade on each machine. Is this procedure recommended or will there be any problem with this ? Thank you & greetings Wolfgang |
|
From: Piotr R. K. <pio...@mo...> - 2017-02-09 22:02:56
|
Hi Zlatko, > I built and installed Debian packages from the source, but I'm also using some of your own packages, for various servers/clients. I noticed there are no packages for Ubuntu 16.10 (yakkety), but trusty packages seems to work just fine on 16.10, so no big deal. > That's true, we are still working on Ubuntu 16 packages (unfortunately currently there's no ETA) and as you noticed, Ubuntu 14 packages work fine on Ubuntu 16. Best regards, Peter -- Piotr Robert Konopelko MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> > On 09 Feb 2017, at 10:53 PM, Zlatko Čalušić <zca...@bi...> wrote: > > Well, my first upgrade went without a hitch, as expected. 3.0.86 -> 3.0.88. > > I built and installed Debian packages from the source, but I'm also using some of your own packages, for various servers/clients. I noticed there are no packages for Ubuntu 16.10 (yakkety), but trusty packages seems to work just fine on 16.10, so no big deal. > MooseFS is amazing! > > On 09.02.2017 15:17, Zlatko Čalušić wrote: >> That is great news, thanks for informing us! >> See a lot of fixes in there, so I might upgrade sooner rather than later, will report how it went. >> Keep up the good work! >> >> On 09.02.2017 15:12, Piotr Robert Konopelko 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/> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, 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> >> >> -- >> Zlatko >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, 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> > > -- > Zlatko > ------------------------------------------------------------------------------ > 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: Zlatko Č. <zca...@bi...> - 2017-02-09 21:53:52
|
Well, my first upgrade went without a hitch, as expected. 3.0.86 -> 3.0.88. I built and installed Debian packages from the source, but I'm also using some of your own packages, for various servers/clients. I noticed there are no packages for Ubuntu 16.10 (yakkety), but trusty packages seems to work just fine on 16.10, so no big deal. MooseFS is amazing! On 09.02.2017 15:17, Zlatko Čalušić wrote: > > That is great news, thanks for informing us! > > See a lot of fixes in there, so I might upgrade sooner rather than > later, will report how it went. > > Keep up the good work! > > On 09.02.2017 15:12, Piotr Robert Konopelko 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)* >> o (mount) added read cache clean on write (same file access >> using different descriptors) >> o (mount) added missing cond_destroy in readdata.c (fix sent by >> Jakub Ratajczak) >> o (master) fixed initializing packet size for reading >> 'sustained' directory >> o (all) fixed zassert for printing correct statuses in case of >> pthread functions >> >> * *MooseFS 3.0.87-1 (2017-02-01)* >> o (mount) fix fleng in finfo after truncate (patched by Davies Liu) >> o (mount) fix overlapped read (patched by Davies Liu) >> o (mount) fixed invalidating chunk cache after truncate >> o (mount) fixed fleng handling in read worker >> o (mount) fixed handling BREAK state in read worker >> o (mount) changed handling data invalidation in read module >> (sometimes could be less efficient, but it is much more safer) >> o (tools) fixed number parsing (patched by Pawel Gawronski) >> o (cli) fixed printed host/port options >> o (mount) moved pipes from requests to workers (read and write >> - huge decrease of descriptors used by mount) >> o (mount) changed signal to broadcast in rwlock (fixed very >> rare read/write deadlock) >> o (mount) fixed 'open descriptors' leak (lookup(with data for >> open)->open(with cached data)->close) >> o (mount) fixed potential 'race condition' - free csdata during >> access >> o (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)* >>> o (master) fixed leader-follower resynchronization after >>> reconnection (pro only) >>> o (master) fixed rehashing condition in edge/node/chunk >>> hashmaps (change inspired by yinjiawind) >>> >>> * *MooseFS 3.0.85-1 (2016-11-17)* >>> o (mount) fixed memory leak (also efficiency) on Linux and >>> potential segfaults on FreeBSD (negative condition) >>> o (mount) fixed race condition for inode value in write module >>> o (mount) better descriptors handling (lists of free elements) >>> o (mount) better releasing descriptors on FreeBSD >>> o (cs) fixed time condition (patch send by yinjiawind) >>> >>> * *MooseFS 3.0.84-1 (2016-10-06)* >>> o (master) fixed setting acl-default without named users or >>> named groups >>> o (master) fixed master-follower synchronization after setting >>> storage class >>> >>> * *MooseFS 3.0.83-1 (2016-09-30)* >>> o *(cs) changed header size from 5k to 8k (due to 4k-sector >>> hard disks)* >>> >>> * *MooseFS 3.0.82-1 (2016-09-28)* >>> o (all) silenced message about using deprecated parameter >>> 'oom_adj' >>> o (mount) fixed FreeBSD delayed release mechanism >>> o (mount) added rwlock for chunks >>> >>> * *MooseFS 3.0.81-1 (2016-07-25)* >>> o (mount) fixed oom killer disabling (setting oom_adj and >>> oom_score_adj) >>> o (cli) fixed displaying inactive mounts >>> o (mount) added fsync before removing any locks >>> o (daemons) added disabling oom killer (Linux only) >>> o (all) small fixes in manpages >>> o (mount) fixed handling nonblocking lock commands (unlock and >>> try) in both locking mechanisms >>> o (daemons+mount) changed default settings for limiting malloc >>> arenas (Linux only) >>> >>> * *MooseFS 3.0.80-1 (2016-07-13)* >>> o (master) fixed chunk loop (in some cases chunks from the >>> last hash position might be left unchecked) >>> o (master) fixed storage class management (fixed >>> has_***_labels fields) >>> >>> * *MooseFS 3.0.79-1 (2016-07-05)* >>> o (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)* >>> o *(cs) fixed serious error that may cause data corruption >>> during internal rebalance (intr. in 3.0.75)* >>> >>> >>> >>> >>> Best regards, >>> Peter >>> >>> -- >>> >>> MooseFS <https://moosefs.com/> >>> >>> Piotr Robert Konopelko >>> MooseFS Technical Support Engineer >>> e-mail: pio...@mo... >>> <mailto:pio...@mo...> >>> www: https://moosefs.com <https://moosefs.com/> >>> >>> Twitter <https://twitter.com/MooseFS>Facebook >>> <https://www.facebook.com/moosefs>LinkedIn >>> <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 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)* >>>> o (mount) added assertions after packet allocation in master >>>> communication module >>>> o (manpages) fixes related to storage classes >>>> o (all) improved error messages used for storage classes >>>> >>>> * *MooseFS 3.0.76-1 (2016-06-03)* >>>> o (master) fixed resolving multi path for root inode >>>> o (master) fixed licence expiration behaviour (pro only) >>>> >>>> * *MooseFS 3.0.75-1 (2016-04-20)* >>>> o (all) fixed cppcheck warnings/errors (mostly false negatives) >>>> o (cs) added file sparsification during chunk write (also >>>> chunk replication, chunk duplication etc.) >>>> o (mount) fixed write data inefficiency when I/O was >>>> performed by root >>>> o (master) fixed removing too early locked chunks from data >>>> structures >>>> o (tools) fixed reusing local ports (connection to master >>>> returned EADDRNOTAVAIL) >>>> o (all) changed default action from restart to start >>>> o (all) added exiting when user defined config (option -c) >>>> cannot be loaded >>>> o (cs) changed handling chunk filename (dynamic filename >>>> generation - cs should use less memory) >>>> o (netdump) changed 'moose ports only' option to 'port range' >>>> o (mount) limited number of files kept as open after close >>>> o (cs) changed subfolder choosing algorithm >>>> o (mount) changed mutex lock to rw-lock for I/O on the same >>>> descriptor >>>> o (mount) added link to mfsmount from '/sbin/mount.moosefs' >>>> (Linux only) >>>> o (all) introduced "storage classes" (new goal/labels management) >>>> o (master+cs) introduced 'temporary maintenance mode' >>>> (automatic maintenance mode after graceful stop of cs) >>>> o (master+mount) added fix for bug in FreeBSD kernel (kernel >>>> sends truncate before first close - FreeBSD only) >>>> o (cs) fixed setting malloc pools on Linux >>>> >>>> * *MooseFS 3.0.74-1 (2016-03-08)* >>>> o (master) fixed rebalance replication (check for all chunk >>>> copies for destination - not only valid) >>>> o (master+mount) new mechanism for atime+mtime setting during I/O >>>> o (master+mount) new I/O synchronization between different >>>> mounts (with cache invalidation) >>>> o (master+mount) new chunk number/version cache (with >>>> automatic invalidation from master) >>>> o (master) added mapping chunkserver IP classes (allow to >>>> have separate network for I/O and separate for other activity) >>>> o (master) fixed status returned by writechunk after network >>>> down/up >>>> o (master) changed trashtime from seconds to hours >>>> o (master) added METADATA_SAVE_FREQ option (allow to save >>>> metadata less frequently than every hour) >>>> o (master) added using in emergency (endangered chunks) all >>>> available servers for replication (even overloaded and >>>> being maintained) >>>> o (master) added using chunkservers in 'internal rebalance' >>>> state in case of deleting chunks >>>> o (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)* >>>> o (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)* >>>>> o (master) fixed restoring ARCHCHG from changelog >>>>> o (cli+cgi) fixed displaying master list with followers only >>>>> (pro version only) >>>>> o (master) added using size and length quota to fix disk >>>>> usage values (statfs) >>>>> o (master) fixed xattr bug which may lead to data corruption >>>>> and segfaults (intr. in 2.1.1) >>>>> o (master) added 'node_info' packet >>>>> o (tools) added '-p' option to 'mfsdirinfo' - 'precise mode' >>>>> o (master) fixed edge renumeration >>>>> o (master) added detecting of wrong edge numbers and force >>>>> renumeration in such case >>>>> >>>>> * *MooseFS 3.0.72-1 (2016-02-04)* >>>>> o (master+cgi+cli) added global 'umask' option to exports.cfg >>>>> o (all) changed address of FSF in GPL licence text >>>>> o (debian) removed obsolete conffiles >>>>> o (debian) fixed copyright file >>>>> o (mount) fixed parsing mfsmount.cfg (system options like >>>>> nodev,noexec etc. were ommited) >>>>> o (master) changed way how cs internal rebalance state is >>>>> treated by master (as 'grace' state instead of 'overloaded') >>>>> o (mount) fixed bug in read module (setting etab after >>>>> ranges realloc) >>>>> o (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)* >>>>> o (master) added METADATA_SAVE_FREQ option (allow to save >>>>> metadata less frequently than every hour) >>>>> >>>>> * *MooseFS 2.0.87-1 (2016-02-23)* >>>>> o (master) fixed status returned by writechunk after network >>>>> down/up >>>>> >>>>> * *MooseFS 2.0.86-1 (2016-02-22)* >>>>> o (master) fixed initialization of ATIME_MODE >>>>> >>>>> * *MooseFS 2.0.85-1 (2016-02-11)* >>>>> o (master) added ATIME_MODE option to set atime modification >>>>> behaviour >>>>> o (master) added using size and length quota to fix disk >>>>> usage values (statfs) >>>>> o (all) changed address of FSF in GPL licence text >>>>> o (debian) removed obsolete conffiles >>>>> o (debian) fixed copyright file >>>>> o (mount) fixed parsing mfsmount.cfg (system options like >>>>> nodev,noexec etc. were ommited) >>>>> o (tools) removed obsoleted command 'mfssnapshot' >>>>> >>>>> * *MooseFS 2.0.84-1 (2016-01-19)* >>>>> o (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)* >>>>>> o (master) fixed emptying trash issue (intr. in 3.0.64) >>>>>> o (master) fixed possible segfault in chunkservers database >>>>>> (intr. in 3.0.67) >>>>>> o (master) changed trash part choice from nondeterministic >>>>>> to deterministic >>>>>> >>>>>> * *MooseFS 3.0.70-1 (2016-01-19)* >>>>>> o (cgi+cli) fixed displaying info when there are no active >>>>>> masters (intr. in 3.0.67) >>>>>> o (mount+common) refactoring code to be Windows ready >>>>>> o (mount) added option 'mfsflattrash' (makes trash look >>>>>> like before version 3.0.64) >>>>>> o (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/> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> 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 > > -- > Zlatko > > > ------------------------------------------------------------------------------ > 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 -- Zlatko |
|
From: Zlatko Č. <zca...@bi...> - 2017-02-09 14:35:24
|
That is great news, thanks for informing us! See a lot of fixes in there, so I might upgrade sooner rather than later, will report how it went. Keep up the good work! On 09.02.2017 15:12, Piotr Robert Konopelko 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)* > o (mount) added read cache clean on write (same file access > using different descriptors) > o (mount) added missing cond_destroy in readdata.c (fix sent by > Jakub Ratajczak) > o (master) fixed initializing packet size for reading > 'sustained' directory > o (all) fixed zassert for printing correct statuses in case of > pthread functions > > * *MooseFS 3.0.87-1 (2017-02-01)* > o (mount) fix fleng in finfo after truncate (patched by Davies Liu) > o (mount) fix overlapped read (patched by Davies Liu) > o (mount) fixed invalidating chunk cache after truncate > o (mount) fixed fleng handling in read worker > o (mount) fixed handling BREAK state in read worker > o (mount) changed handling data invalidation in read module > (sometimes could be less efficient, but it is much more safer) > o (tools) fixed number parsing (patched by Pawel Gawronski) > o (cli) fixed printed host/port options > o (mount) moved pipes from requests to workers (read and write - > huge decrease of descriptors used by mount) > o (mount) changed signal to broadcast in rwlock (fixed very rare > read/write deadlock) > o (mount) fixed 'open descriptors' leak (lookup(with data for > open)->open(with cached data)->close) > o (mount) fixed potential 'race condition' - free csdata during > access > o (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)* >> o (master) fixed leader-follower resynchronization after >> reconnection (pro only) >> o (master) fixed rehashing condition in edge/node/chunk >> hashmaps (change inspired by yinjiawind) >> >> * *MooseFS 3.0.85-1 (2016-11-17)* >> o (mount) fixed memory leak (also efficiency) on Linux and >> potential segfaults on FreeBSD (negative condition) >> o (mount) fixed race condition for inode value in write module >> o (mount) better descriptors handling (lists of free elements) >> o (mount) better releasing descriptors on FreeBSD >> o (cs) fixed time condition (patch send by yinjiawind) >> >> * *MooseFS 3.0.84-1 (2016-10-06)* >> o (master) fixed setting acl-default without named users or >> named groups >> o (master) fixed master-follower synchronization after setting >> storage class >> >> * *MooseFS 3.0.83-1 (2016-09-30)* >> o *(cs) changed header size from 5k to 8k (due to 4k-sector >> hard disks)* >> >> * *MooseFS 3.0.82-1 (2016-09-28)* >> o (all) silenced message about using deprecated parameter 'oom_adj' >> o (mount) fixed FreeBSD delayed release mechanism >> o (mount) added rwlock for chunks >> >> * *MooseFS 3.0.81-1 (2016-07-25)* >> o (mount) fixed oom killer disabling (setting oom_adj and >> oom_score_adj) >> o (cli) fixed displaying inactive mounts >> o (mount) added fsync before removing any locks >> o (daemons) added disabling oom killer (Linux only) >> o (all) small fixes in manpages >> o (mount) fixed handling nonblocking lock commands (unlock and >> try) in both locking mechanisms >> o (daemons+mount) changed default settings for limiting malloc >> arenas (Linux only) >> >> * *MooseFS 3.0.80-1 (2016-07-13)* >> o (master) fixed chunk loop (in some cases chunks from the last >> hash position might be left unchecked) >> o (master) fixed storage class management (fixed has_***_labels >> fields) >> >> * *MooseFS 3.0.79-1 (2016-07-05)* >> o (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)* >> o *(cs) fixed serious error that may cause data corruption >> during internal rebalance (intr. in 3.0.75)* >> >> >> >> >> Best regards, >> Peter >> >> -- >> >> MooseFS <https://moosefs.com/> >> >> Piotr Robert Konopelko >> MooseFS Technical Support Engineer >> e-mail: pio...@mo... <mailto:pio...@mo...> >> www: https://moosefs.com <https://moosefs.com/> >> >> Twitter <https://twitter.com/MooseFS>Facebook >> <https://www.facebook.com/moosefs>LinkedIn >> <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 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)* >>> o (mount) added assertions after packet allocation in master >>> communication module >>> o (manpages) fixes related to storage classes >>> o (all) improved error messages used for storage classes >>> >>> * *MooseFS 3.0.76-1 (2016-06-03)* >>> o (master) fixed resolving multi path for root inode >>> o (master) fixed licence expiration behaviour (pro only) >>> >>> * *MooseFS 3.0.75-1 (2016-04-20)* >>> o (all) fixed cppcheck warnings/errors (mostly false negatives) >>> o (cs) added file sparsification during chunk write (also >>> chunk replication, chunk duplication etc.) >>> o (mount) fixed write data inefficiency when I/O was performed >>> by root >>> o (master) fixed removing too early locked chunks from data >>> structures >>> o (tools) fixed reusing local ports (connection to master >>> returned EADDRNOTAVAIL) >>> o (all) changed default action from restart to start >>> o (all) added exiting when user defined config (option -c) >>> cannot be loaded >>> o (cs) changed handling chunk filename (dynamic filename >>> generation - cs should use less memory) >>> o (netdump) changed 'moose ports only' option to 'port range' >>> o (mount) limited number of files kept as open after close >>> o (cs) changed subfolder choosing algorithm >>> o (mount) changed mutex lock to rw-lock for I/O on the same >>> descriptor >>> o (mount) added link to mfsmount from '/sbin/mount.moosefs' >>> (Linux only) >>> o (all) introduced "storage classes" (new goal/labels management) >>> o (master+cs) introduced 'temporary maintenance mode' >>> (automatic maintenance mode after graceful stop of cs) >>> o (master+mount) added fix for bug in FreeBSD kernel (kernel >>> sends truncate before first close - FreeBSD only) >>> o (cs) fixed setting malloc pools on Linux >>> >>> * *MooseFS 3.0.74-1 (2016-03-08)* >>> o (master) fixed rebalance replication (check for all chunk >>> copies for destination - not only valid) >>> o (master+mount) new mechanism for atime+mtime setting during I/O >>> o (master+mount) new I/O synchronization between different >>> mounts (with cache invalidation) >>> o (master+mount) new chunk number/version cache (with >>> automatic invalidation from master) >>> o (master) added mapping chunkserver IP classes (allow to have >>> separate network for I/O and separate for other activity) >>> o (master) fixed status returned by writechunk after network >>> down/up >>> o (master) changed trashtime from seconds to hours >>> o (master) added METADATA_SAVE_FREQ option (allow to save >>> metadata less frequently than every hour) >>> o (master) added using in emergency (endangered chunks) all >>> available servers for replication (even overloaded and being >>> maintained) >>> o (master) added using chunkservers in 'internal rebalance' >>> state in case of deleting chunks >>> o (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)* >>> o (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)* >>>> o (master) fixed restoring ARCHCHG from changelog >>>> o (cli+cgi) fixed displaying master list with followers only >>>> (pro version only) >>>> o (master) added using size and length quota to fix disk >>>> usage values (statfs) >>>> o (master) fixed xattr bug which may lead to data corruption >>>> and segfaults (intr. in 2.1.1) >>>> o (master) added 'node_info' packet >>>> o (tools) added '-p' option to 'mfsdirinfo' - 'precise mode' >>>> o (master) fixed edge renumeration >>>> o (master) added detecting of wrong edge numbers and force >>>> renumeration in such case >>>> >>>> * *MooseFS 3.0.72-1 (2016-02-04)* >>>> o (master+cgi+cli) added global 'umask' option to exports.cfg >>>> o (all) changed address of FSF in GPL licence text >>>> o (debian) removed obsolete conffiles >>>> o (debian) fixed copyright file >>>> o (mount) fixed parsing mfsmount.cfg (system options like >>>> nodev,noexec etc. were ommited) >>>> o (master) changed way how cs internal rebalance state is >>>> treated by master (as 'grace' state instead of 'overloaded') >>>> o (mount) fixed bug in read module (setting etab after ranges >>>> realloc) >>>> o (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)* >>>> o (master) added METADATA_SAVE_FREQ option (allow to save >>>> metadata less frequently than every hour) >>>> >>>> * *MooseFS 2.0.87-1 (2016-02-23)* >>>> o (master) fixed status returned by writechunk after network >>>> down/up >>>> >>>> * *MooseFS 2.0.86-1 (2016-02-22)* >>>> o (master) fixed initialization of ATIME_MODE >>>> >>>> * *MooseFS 2.0.85-1 (2016-02-11)* >>>> o (master) added ATIME_MODE option to set atime modification >>>> behaviour >>>> o (master) added using size and length quota to fix disk >>>> usage values (statfs) >>>> o (all) changed address of FSF in GPL licence text >>>> o (debian) removed obsolete conffiles >>>> o (debian) fixed copyright file >>>> o (mount) fixed parsing mfsmount.cfg (system options like >>>> nodev,noexec etc. were ommited) >>>> o (tools) removed obsoleted command 'mfssnapshot' >>>> >>>> * *MooseFS 2.0.84-1 (2016-01-19)* >>>> o (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)* >>>>> o (master) fixed emptying trash issue (intr. in 3.0.64) >>>>> o (master) fixed possible segfault in chunkservers database >>>>> (intr. in 3.0.67) >>>>> o (master) changed trash part choice from nondeterministic >>>>> to deterministic >>>>> >>>>> * *MooseFS 3.0.70-1 (2016-01-19)* >>>>> o (cgi+cli) fixed displaying info when there are no active >>>>> masters (intr. in 3.0.67) >>>>> o (mount+common) refactoring code to be Windows ready >>>>> o (mount) added option 'mfsflattrash' (makes trash look like >>>>> before version 3.0.64) >>>>> o (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/> >>>>> >>>> >>>> >>> >>> >> > > > > ------------------------------------------------------------------------------ > 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 -- Zlatko |
|
From: Wilson, S. M <st...@pu...> - 2017-02-09 14:14:27
|
?Hi, I recently added several SSD chunk servers and a new storage class to one of our MooseFS installations and began to see a lot of chatter from mfsmaster in the log files. Here's a sample: ? Feb 9 07:01:15 massachusetts mfsmaster[24264]: chunk 00000000141D2404_00000002: chunk in middle of operation TRUNCATE, but no chunk server is busy - finish operation Feb 9 07:01:16 massachusetts mfsmaster[24264]: got replication status from server which had had that chunk before (chunk:00000000141D2404_00000002) Feb 9 07:03:04 massachusetts mfsmaster[24264]: chunk 00000000141D23FB_00000002: unexpected BUSY copies - fixing Feb 9 07:03:04 massachusetts mfsmaster[24264]: chunk 00000000141D242B_00000002: chunk in middle of operation TRUNCATE, but no chunk server is busy - finish operation Feb 9 07:03:05 massachusetts mfsmaster[24264]: got replication status from server which had had that chunk before (chunk:00000000141D242B_00000002) Feb 9 07:03:14 massachusetts mfsmaster[24264]: chunk 00000000141D2434_00000002: chunk in middle of operation TRUNCATE, but no chunk server is busy - finish operation Feb 9 07:03:14 massachusetts mfsmaster[24264]: got replication status from server which had had that chunk before (chunk:00000000141D2434_00000002) Feb 9 07:03:18 massachusetts mfsmaster[24264]: chunk 00000000141D2404_00000002: unexpected BUSY copies - fixing Feb 9 07:03:18 massachusetts mfsmaster[24264]: chunk 00000000141D2436_00000002: chunk in middle of operation TRUNCATE, but no chunk server is busy - finish operation Feb 9 07:03:18 massachusetts mfsmaster[24264]: got replication status from server which had had that chunk before (chunk:00000000141D2436_00000002) Feb 9 07:03:24 massachusetts mfsmaster[24264]: chunk 00000000141D243A_00000002: chunk in middle of operation TRUNCATE, but no chunk server is busy - finish operation Feb 9 07:03:24 massachusetts mfsmaster[24264]: got replication status from server which had had that chunk before (chunk:00000000141D243A_00000002) ?? This has happened before and as I recall it eventually settled down and the messages went away... after about five or six weeks. Does anyone know what causes these messages? I assume that they're harmless; is that true? Thanks, Steve |
|
From: Piotr R. K. <pio...@mo...> - 2017-02-09 14:13:08
|
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...> 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: Wilson, S. M <st...@pu...> - 2017-02-08 18:26:59
|
________________________________________
From: WK <wk...@bn...>
Sent: Wednesday, February 8, 2017 1:00 PM
To: moo...@li...
Subject: Re: [MooseFS-Users] Two mounts or one? what has better performance
On 2/6/2017 10:52 AM, Wilson, Steven M wrote:
>
>> Also, copying/moving files between mountpoints is going to be slower than if
>> you have files and backup on the same mountpoint.
> The difference is quite substantial when moving files since it only takes a few seconds to make the necessary metadata updates when moving files under the same mount point. I usually have two mount points for each of my MooseFS file systems, a home/data mount point ("/home" inside MooseFS) and a scratch mount point ("/scratch" inside MooseFS). But if I ever need to move a large amount of data from one to the other, I'll temporarily create a mount point that is at the root of the of the MooseFS file system ("/") just to execute the move.
So assuming there normal is little interaction between two file systems,
(i.e. where the cache would help or things are moved back and forth). I
like the temp mount idea and will keep that in mind.
I take it two seperate mounts is a better strategy?
Im worried about resources limits per mount etc. (though the defaults
look pretty generous). CPU consumption (i.e. two fuse mounts more work
than one?) etc.
-wk
I would recommend using two separate mounts for what you are doing. Each FUSE mount doesn't consume much CPU or memory resource, especially when not in active use.
~ Steve
|
|
From: WK <wk...@bn...> - 2017-02-08 18:01:05
|
On 2/6/2017 10:52 AM, Wilson, Steven M wrote:
>
>> Also, copying/moving files between mountpoints is going to be slower than if
>> you have files and backup on the same mountpoint.
> The difference is quite substantial when moving files since it only takes a few seconds to make the necessary metadata updates when moving files under the same mount point. I usually have two mount points for each of my MooseFS file systems, a home/data mount point ("/home" inside MooseFS) and a scratch mount point ("/scratch" inside MooseFS). But if I ever need to move a large amount of data from one to the other, I'll temporarily create a mount point that is at the root of the of the MooseFS file system ("/") just to execute the move.
So assuming there normal is little interaction between two file systems,
(i.e. where the cache would help or things are moved back and forth). I
like the temp mount idea and will keep that in mind.
I take it two seperate mounts is a better strategy?
Im worried about resources limits per mount etc. (though the defaults
look pretty generous). CPU consumption (i.e. two fuse mounts more work
than one?) etc.
-wk
|
|
From: Wilson, S. M <st...@pu...> - 2017-02-06 18:52:31
|
________________________________________
From: Ricardo J. Barberis <ric...@do...>
Sent: Monday, February 6, 2017 1:38 PM
To: moo...@li...
Subject: Re: [MooseFS-Users] Two mounts or one? what has better performance
El Lunes 06/02/2017, Jakub Kruszona-Zawadzki escribió:
>> The main difference will be cache. In case of one mount you will have one
>> cache shared between users ('files' folder) and your backup ('backup'
>> folder). In case of two mounts you will have two independent caches. I do
>> not expect big difference but still it may improve a little bit.
> Also, copying/moving files between mountpoints is going to be slower than if
> you have files and backup on the same mountpoint.
The difference is quite substantial when moving files since it only takes a few seconds to make the necessary metadata updates when moving files under the same mount point. I usually have two mount points for each of my MooseFS file systems, a home/data mount point ("/home" inside MooseFS) and a scratch mount point ("/scratch" inside MooseFS). But if I ever need to move a large amount of data from one to the other, I'll temporarily create a mount point that is at the root of the of the MooseFS file system ("/") just to execute the move.
Steve
_________________________________________
moosefs-users mailing list
moo...@li...
https://lists.sourceforge.net/lists/listinfo/moosefs-users
|
|
From: Ricardo J. B. <ric...@do...> - 2017-02-06 18:38:32
|
El Lunes 06/02/2017, Jakub Kruszona-Zawadzki escribió:
> On 2 Feb, 2017, at 19:28, WK <wk...@bn...> wrote:
> > We have a project where we have a machine that is talking to a MFS3
> > cluster for two purposes
> >
> > The main purpose is a very busy file repo, we are also copying off large
> > archives in to a backup folder 2-3 times a day.
> >
> > We want to reduce latency on the files as the client is somewhat picky
> > and want to avoid the archive dump slowing things down.
> >
> > What is the best way to handle that
> >
> > A) one mfsmount to /mfs3mnt
> >
> > with subdirectory /mfs3mnt/backup & /mfs3mnt/files
> >
> >
> > b) Two seperate mfsmounts on the client
> >
> > /mfs3backup
> >
> > and
> >
> > /mfs3files
> >
> > Security isolation is not a concern.
> >
> > So what would provide the best performance? or does it really matter?
> >
> > The connection would be 1GB ethernet with jumbo frames.
> >
> >
> > Note we are considering that with two mounts we could use seperate
> > ethernet cards, however its not an option immediately as the host has
> > used up all the ports with other needs.
> >
> > If you feel strongly that would make a difference then I can push a host
> > migration on the client.
> >
> > And of course 10G is getting reasonable, but still not a default on our
> > somewhat older kit.
> >
> > -wk
>
> The main difference will be cache. In case of one mount you will have one
> cache shared between users ('files' folder) and your backup ('backup'
> folder). In case of two mounts you will have two independent caches. I do
> not expect big difference but still it may improve a little bit.
Also, copying/moving files between mountpoints is going to be slower than if
you have files and backup on the same mountpoint.
PS: Jakub, is this your signature or something went wrong?:
"Segmentation fault (core dumped)"
Cheers,
--
Ricardo J. Barberis
Senior SysAdmin / IT Architect
DonWeb
La Actitud Es Todo
www.DonWeb.com
_____
|
|
From: Jakub Kruszona-Z. <jak...@ge...> - 2017-02-06 10:36:19
|
On 2 Feb, 2017, at 19:28, WK <wk...@bn...> wrote: > We have a project where we have a machine that is talking to a MFS3 > cluster for two purposes > > The main purpose is a very busy file repo, we are also copying off large > archives in to a backup folder 2-3 times a day. > > We want to reduce latency on the files as the client is somewhat picky > and want to avoid the archive dump slowing things down. > > What is the best way to handle that > > A) one mfsmount to /mfs3mnt > > with subdirectory /mfs3mnt/backup & /mfs3mnt/files > > > b) Two seperate mfsmounts on the client > > /mfs3backup > > and > > /mfs3files > > Security isolation is not a concern. > > So what would provide the best performance? or does it really matter? > > The connection would be 1GB ethernet with jumbo frames. > > > Note we are considering that with two mounts we could use seperate > ethernet cards, however its not an option immediately as the host has > used up all the ports with other needs. > > If you feel strongly that would make a difference then I can push a host > migration on the client. > > And of course 10G is getting reasonable, but still not a default on our > somewhat older kit. > > -wk > > > > > ------------------------------------------------------------------------------ > 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 The main difference will be cache. In case of one mount you will have one cache shared between users ('files' folder) and your backup ('backup' folder). In case of two mounts you will have two independent caches. I do not expect big difference but still it may improve a little bit. -- Regards, Jakub Kruszona-Zawadzki - - - - - - - - - - - - - - - - Segmentation fault (core dumped) Phone: +48 602 212 039 |
|
From: WK <wk...@bn...> - 2017-02-02 18:47:11
|
We have a project where we have a machine that is talking to a MFS3 cluster for two purposes The main purpose is a very busy file repo, we are also copying off large archives in to a backup folder 2-3 times a day. We want to reduce latency on the files as the client is somewhat picky and want to avoid the archive dump slowing things down. What is the best way to handle that A) one mfsmount to /mfs3mnt with subdirectory /mfs3mnt/backup & /mfs3mnt/files b) Two seperate mfsmounts on the client /mfs3backup and /mfs3files Security isolation is not a concern. So what would provide the best performance? or does it really matter? The connection would be 1GB ethernet with jumbo frames. Note we are considering that with two mounts we could use seperate ethernet cards, however its not an option immediately as the host has used up all the ports with other needs. If you feel strongly that would make a difference then I can push a host migration on the client. And of course 10G is getting reasonable, but still not a default on our somewhat older kit. -wk |
|
From: Wilson, S. M <st...@pu...> - 2017-01-20 14:38:30
|
Hi,
In one of my MooseFS installations, I decided to add several SSD-based chunk servers in addition to the existing two chunk servers filled with spinning disks.? I would use storage classes to create a tiered storage system where frequently accessed files are kept on the SSD chunk servers and less frequently used files on the slower chunk servers with hard drives. I created a storage class with the following options:
"-C2A -K2A,B -A2B -d7 ssd-cache"
The SSD chunk servers all belong to class A and the hard drive chunk servers belong to class B. Additionally, I will use the "mfspreflabels=A" mfsmount option to give preference to the SSD chunk servers.
Yesterday, I assigned my entire MooseFS directory tree to the newly-created storage class "ssd-cache". Before doing this, the directory tree as assigned to a simple directory class that requires two copes of each file on the hard drive chunk servers:
"-K2B hd-only"
After changing the storage class on the whole directory tree, it looks like all files, regardless of when they were last modified, are now being moved to the SSD chunk servers. I assumed that any files that haven't been modified in the past 7 days ("-d7") would remain on the hard drive chunk servers ("-A2B") and not be moved to the SSD chunk servers. Is this the expected behavior, or is it a bug? Is there a better way to transition all my data over to the new storage class that will only move recently modified files to the SSD chunk servers?
BTW, I am using the latest MooseFS version, 3.0.86-1.
?Thanks!
Steve
|
|
From: Markus K. <mar...@tu...> - 2017-01-13 13:06:13
|
On Thursday 12 January 2017 18:38:02 Marcin wrote: > W dniu 2017-01-12 18:16, Aleksander Wieliczko napisał(a): > > Hi, > > Would you be so kind and tell us something more about your „two node” > > cluster configuration. > > I mean what kind of CPU is on mfsmaster and chunkserver? > > Sepicfy amount of RAM on each server? > > How many hard disk you have inside you chunkserver and how fast they > > are? > > What is you LAN configuration: NIC devices, ping size between > > chunkserver, master and client. > > > > By the way I would like to add that minimum configration is: > > 1x MooseFS master server > > 3x MooseFS chunkserver. > > > Cześć Aleksander, > node with mfsmaster & chunkserver: > CPU - E5440 - 8 cores, 2.83GHz > $ free -m > total used free shared buff/cache > available > Mem: 3946 2497 136 64 1312 > 1067 > Swap: 4091 1322 2769 > > second node with chunkserver: > CPU - X3230 - 4 cores, 2.66GHz > $ free -m > total used free shared buff/cache > available > Mem: 1998 426 81 36 1490 > 1345 > Swap: 2043 1436 607 > > > Both nodes uses 7.2k HDD, nodes are connected using 1GB ethernet. This > is local LAN, ping is below 0.2 ms. > Problem with data access is on second node. > I'm going to add more chunkservers but I have to migrate services from > phisical machines to VM. I can't do it because I'm observing stability > problem... > > Marcin It seams your are very short with RAM. You can find the requirements in this document: https://moosefs.com/Content/Downloads/moosefs-3-0-users-manual.pdf regards, Markus Köberl -- Markus Koeberl Graz University of Technology Signal Processing and Speech Communication Laboratory E-mail: mar...@tu... |
|
From: <ma...@me...> - 2017-01-13 11:36:00
|
W dniu 12.01.2017 o 18:38, Marcin pisze: > W dniu 2017-01-12 18:16, Aleksander Wieliczko napisał(a): >> By the way I would like to add that minimum configration is: >> 1x MooseFS master server >> 3x MooseFS chunkserver. Hi! I've added third node with chunkserver. It doesn't fix described problem. Marcin |
|
From: Markus K. <mar...@tu...> - 2017-01-13 09:04:54
|
Hi!
If you are running chunk servers on a separate network and one of them is not reachable on this network the Disks tab on the web interface does not work. The confusing thing is that on the Servers tab and on the Info tab everything is alright.
It would be nice if the case would get handled so that the information of all other chunk servers get displayed and the timeout gets displayed int the lines for the the disks of the affected chunk server.
web interface output:
Traceback (most recent call last):
File "/usr/share/mfscgi/mfs.cgi", line 4481, in
conn = MFSConn(hostip,port)
File "/usr/share/mfscgi/mfs.cgi", line 1348, in __init__
self.connect()
File "/usr/share/mfscgi/mfs.cgi", line 1371, in connect
self.socket.connect((self.host,self.port))
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
timeout: timed out
my configuration:
moosefs 3.0.86-1
all hosts have configured a public IP and private IP
master:
MATOML_LISTEN_HOST = *
MATOCS_LISTEN_HOST = *
MATOCL_LISTEN_HOST = *
chunkserver:
BIND_HOST = public IP
MASTER_HOST = public IP master
CSSERV_LISTEN_HOST = private IP
To reproduce it disconnect the network cable for the private IP of one chunk server.
Thanks,
Markus Köberl
--
Markus Koeberl
Graz University of Technology
Signal Processing and Speech Communication Laboratory
E-mail: mar...@tu...
|
|
From: Marcin <ma...@me...> - 2017-01-12 17:38:59
|
W dniu 2017-01-12 18:16, Aleksander Wieliczko napisał(a):
> Hi,
> Would you be so kind and tell us something more about your „two node”
> cluster configuration.
> I mean what kind of CPU is on mfsmaster and chunkserver?
> Sepicfy amount of RAM on each server?
> How many hard disk you have inside you chunkserver and how fast they
> are?
> What is you LAN configuration: NIC devices, ping size between
> chunkserver, master and client.
>
> By the way I would like to add that minimum configration is:
> 1x MooseFS master server
> 3x MooseFS chunkserver.
Cześć Aleksander,
node with mfsmaster & chunkserver:
CPU - E5440 - 8 cores, 2.83GHz
$ free -m
total used free shared buff/cache
available
Mem: 3946 2497 136 64 1312
1067
Swap: 4091 1322 2769
second node with chunkserver:
CPU - X3230 - 4 cores, 2.66GHz
$ free -m
total used free shared buff/cache
available
Mem: 1998 426 81 36 1490
1345
Swap: 2043 1436 607
Both nodes uses 7.2k HDD, nodes are connected using 1GB ethernet. This
is local LAN, ping is below 0.2 ms.
Problem with data access is on second node.
I'm going to add more chunkservers but I have to migrate services from
phisical machines to VM. I can't do it because I'm observing stability
problem...
Marcin
|
|
From: Aleksander W. <ale...@mo...> - 2017-01-12 17:17:10
|
Hi, Would you be so kind and tell us something more about your „two node” cluster configuration. I mean what kind of CPU is on mfsmaster and chunkserver? Sepicfy amount of RAM on each server? How many hard disk you have inside you chunkserver and how fast they are? What is you LAN configuration: NIC devices, ping size between chunkserver, master and client. By the way I would like to add that minimum configration is: 1x MooseFS master server 3x MooseFS chunkserver. Best Regards Aleksander > On 12 sty 2017, at 15:50, ma...@me... wrote: > > W dniu 11.01.2017 o 17:54, ma...@me... pisze: >> Hi! >> I'm using moosefs-3.0.86 on ubuntu 16. This is two node setup. On second >> node - node without mfsmaster, only with mfschunkserver, I'm starting >> qemu VM (parameters for qemu: [...] -drive >> file=/var/lib/one//datastores/101/42/disk.0,format=qcow2,if=none,id=drive-virtio-disk0,cache=none >> -device >> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,logical_block_size=512,physical_block_size=4096 >> [...] ) >> >> When high I/O starts inside VM then qcow file with vm image becomes >> unreadable. OS inside qemu hangs. When I run md5sum on qcow file it also >> stuck in D state after reading some part of file. >> There is nothing suspicious in syslog. On mfsmaster I have: >>> Jan 11 16:57:27 w2t-cl-a-00 mfsmount[15828]: high packet travel time between client and master (0.248819s) - ignoring in time sync >>> Jan 11 17:00:00 w2t-cl-a-00 mfsmaster[2501]: no metaloggers connected !!! >>> Jan 11 17:00:03 w2t-cl-a-00 mfsmaster[2501]: child finished >>> Jan 11 17:00:03 w2t-cl-a-00 mfsmaster[2501]: store process has finished - store time: 3.750 >> >> [here, about 17:25 vm stuck in D state] > > In dmesg I've got: >> [ 3960.108053] INFO: task qemu-system-x86:25093 blocked for more than 120 seconds. >> [ 3960.108169] Not tainted 4.4.0-59-generic #80-Ubuntu >> [ 3960.108255] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >> [ 3960.108366] qemu-system-x86 D ffff880053a2fd38 0 25093 1 0x00000000 >> [ 3960.108373] ffff880053a2fd38 ffffffff81101066 ffff88003562bfc0 ffff88007916bfc0 >> [ 3960.108377] ffff880053a30000 ffff880078cfb3ac ffff88007916bfc0 00000000ffffffff >> [ 3960.108382] ffff880078cfb3b0 ffff880053a2fd50 ffffffff818343f5 ffff880078cfb3a8 >> [ 3960.108386] Call Trace: >> [ 3960.108396] [<ffffffff81101066>] ? futex_wait+0x206/0x280 >> [ 3960.108402] [<ffffffff818343f5>] schedule+0x35/0x80 >> [ 3960.108405] [<ffffffff8183469e>] schedule_preempt_disabled+0xe/0x10 >> [ 3960.108409] [<ffffffff818362d9>] __mutex_lock_slowpath+0xb9/0x130 >> [ 3960.108412] [<ffffffff8183636f>] mutex_lock+0x1f/0x30 >> [ 3960.108416] [<ffffffff8132335a>] fuse_file_write_iter+0x7a/0x2e0 >> [ 3960.108421] [<ffffffff8120e11b>] new_sync_write+0x9b/0xe0 >> [ 3960.108425] [<ffffffff8120e186>] __vfs_write+0x26/0x40 >> [ 3960.108428] [<ffffffff8120eb09>] vfs_write+0xa9/0x1a0 >> [ 3960.108432] [<ffffffff8120f975>] SyS_pwrite64+0x95/0xb0 >> [ 3960.108436] [<ffffffff818384f2>] entry_SYSCALL_64_fastpath+0x16/0x71 > > > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: <ma...@me...> - 2017-01-12 14:50:59
|
W dniu 11.01.2017 o 17:54, ma...@me... pisze: > Hi! > I'm using moosefs-3.0.86 on ubuntu 16. This is two node setup. On second > node - node without mfsmaster, only with mfschunkserver, I'm starting > qemu VM (parameters for qemu: [...] -drive > file=/var/lib/one//datastores/101/42/disk.0,format=qcow2,if=none,id=drive-virtio-disk0,cache=none > -device > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,logical_block_size=512,physical_block_size=4096 > [...] ) > > When high I/O starts inside VM then qcow file with vm image becomes > unreadable. OS inside qemu hangs. When I run md5sum on qcow file it also > stuck in D state after reading some part of file. > There is nothing suspicious in syslog. On mfsmaster I have: >> Jan 11 16:57:27 w2t-cl-a-00 mfsmount[15828]: high packet travel time between client and master (0.248819s) - ignoring in time sync >> Jan 11 17:00:00 w2t-cl-a-00 mfsmaster[2501]: no metaloggers connected !!! >> Jan 11 17:00:03 w2t-cl-a-00 mfsmaster[2501]: child finished >> Jan 11 17:00:03 w2t-cl-a-00 mfsmaster[2501]: store process has finished - store time: 3.750 > > [here, about 17:25 vm stuck in D state] In dmesg I've got: > [ 3960.108053] INFO: task qemu-system-x86:25093 blocked for more than 120 seconds. > [ 3960.108169] Not tainted 4.4.0-59-generic #80-Ubuntu > [ 3960.108255] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 3960.108366] qemu-system-x86 D ffff880053a2fd38 0 25093 1 0x00000000 > [ 3960.108373] ffff880053a2fd38 ffffffff81101066 ffff88003562bfc0 ffff88007916bfc0 > [ 3960.108377] ffff880053a30000 ffff880078cfb3ac ffff88007916bfc0 00000000ffffffff > [ 3960.108382] ffff880078cfb3b0 ffff880053a2fd50 ffffffff818343f5 ffff880078cfb3a8 > [ 3960.108386] Call Trace: > [ 3960.108396] [<ffffffff81101066>] ? futex_wait+0x206/0x280 > [ 3960.108402] [<ffffffff818343f5>] schedule+0x35/0x80 > [ 3960.108405] [<ffffffff8183469e>] schedule_preempt_disabled+0xe/0x10 > [ 3960.108409] [<ffffffff818362d9>] __mutex_lock_slowpath+0xb9/0x130 > [ 3960.108412] [<ffffffff8183636f>] mutex_lock+0x1f/0x30 > [ 3960.108416] [<ffffffff8132335a>] fuse_file_write_iter+0x7a/0x2e0 > [ 3960.108421] [<ffffffff8120e11b>] new_sync_write+0x9b/0xe0 > [ 3960.108425] [<ffffffff8120e186>] __vfs_write+0x26/0x40 > [ 3960.108428] [<ffffffff8120eb09>] vfs_write+0xa9/0x1a0 > [ 3960.108432] [<ffffffff8120f975>] SyS_pwrite64+0x95/0xb0 > [ 3960.108436] [<ffffffff818384f2>] entry_SYSCALL_64_fastpath+0x16/0x71 |
|
From: <ma...@me...> - 2017-01-11 17:12:58
|
Hi! I'm using moosefs-3.0.86 on ubuntu 16. This is two node setup. On second node - node without mfsmaster, only with mfschunkserver, I'm starting qemu VM (parameters for qemu: [...] -drive file=/var/lib/one//datastores/101/42/disk.0,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,logical_block_size=512,physical_block_size=4096 [...] ) When high I/O starts inside VM then qcow file with vm image becomes unreadable. OS inside qemu hangs. When I run md5sum on qcow file it also stuck in D state after reading some part of file. There is nothing suspicious in syslog. On mfsmaster I have: > Jan 11 16:57:27 w2t-cl-a-00 mfsmount[15828]: high packet travel time between client and master (0.248819s) - ignoring in time sync > Jan 11 17:00:00 w2t-cl-a-00 mfsmaster[2501]: no metaloggers connected !!! > Jan 11 17:00:03 w2t-cl-a-00 mfsmaster[2501]: child finished > Jan 11 17:00:03 w2t-cl-a-00 mfsmaster[2501]: store process has finished - store time: 3.750 [here, about 17:25 vm stuck in D state] > Jan 11 17:41:02 w2t-cl-a-00 mfsmaster[2501]: structure check loop How to fix it? How to debug it? Thanks, Marcin |
|
From: Aleksander W. <ale...@mo...> - 2016-12-27 06:42:47
|
Hi, Can we get some more detailed information? Which MosoeFS version you have and what you mean that metadata is messed up? Please check directory information with mfsdirinfo -p tool. Do you have any log files from MooseFS master and from MooseFS client machines? Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 12/26/2016 06:03 PM, web user wrote: > Hi, > > We had a user who was using mfs from Mac OSX and everything was > working fine. He connected from a different location via VPN and his > meta data is all messed up and showing different the same file sizes > for all the folders. This now happens even when he has returned to our > office and is not longer connected to VPN. We also tried a reboot and > he still sees obviously incorrect values over du -h. > > Any suggestions on what we can do. ? > > WU |
|
From: web u. <web...@gm...> - 2016-12-26 17:04:01
|
Hi, We had a user who was using mfs from Mac OSX and everything was working fine. He connected from a different location via VPN and his meta data is all messed up and showing different the same file sizes for all the folders. This now happens even when he has returned to our office and is not longer connected to VPN. We also tried a reboot and he still sees obviously incorrect values over du -h. Any suggestions on what we can do. ? WU |
|
From: Piotr R. K. <pio...@mo...> - 2016-12-24 01:19:24
|
<div dir='auto'>Hi,<div dir="auto"><br></div><div dir="auto">it's not a problem - you can safely use MooseFS Trusty repo for Xenial.</div><div dir="auto"><br></div><div dir="auto">We are in progress of preparing native Ubuntu Xenial with systemd support.<br><br><div data-smartmail="gmail_signature" dir="auto"><br>Best regards,<br>Peter<br><br>Piotr Robert Konopelko <br>MooseFS Technical Support Engineer <br>e-mail: pio...@mo... <br>www: https://moosefs.com<br><br>// Sent from my phone, sorry for condensed form</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 24, 2016 1:35 AM, WK <wk...@bn...> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> <p>Not seeing it in the repo mentioned on the website.</p> <p>Trusty (14) seems to work fine with a manual install. Any issues using that for just the mfsmount?<br /> </p> <h1>Index of /moosefs-3/apt/ubuntu</h1> <table><tbody><tr><th><img src="cid:part1.04C55303.B822179A@bneit.com" alt="[ICO]" /></th><th><a href="http://ppa.moosefs.com/moosefs-3/apt/ubuntu/?C=N;O=D">Name</a></th><th><a href="http://ppa.moosefs.com/moosefs-3/apt/ubuntu/?C=M;O=A">Last modified</a></th><th><a href="http://ppa.moosefs.com/moosefs-3/apt/ubuntu/?C=S;O=A">Size</a></th><th><a href="http://ppa.moosefs.com/moosefs-3/apt/ubuntu/?C=D;O=A">Description</a></th></tr><tr><th colspan="5"> <hr /></th></tr><tr><td valign="top"><img src="cid:part6.FE23CE88.FD43B1C2@bneit.com" alt="[DIR]" /></td><td><a href="http://ppa.moosefs.com/moosefs-3/apt/">Parent Directory</a></td><td> </td><td align="right"> - </td><td> </td></tr><tr><td valign="top"><img src="cid:part8.252C9772.B02375E4@bneit.com" alt="[DIR]" /></td><td><a href="http://ppa.moosefs.com/moosefs-3/apt/ubuntu/lucid/">lucid/</a></td><td align="right">30-Nov-2016 18:42 </td><td align="right"> - </td><td> </td></tr><tr><td valign="top"><img src="cid:part8.252C9772.B02375E4@bneit.com" alt="[DIR]" /></td><td><a href="http://ppa.moosefs.com/moosefs-3/apt/ubuntu/maverick/">maverick/</a></td><td align="right">30-Nov-2016 18:42 </td><td align="right"> - </td><td> </td></tr><tr><td valign="top"><img src="cid:part8.252C9772.B02375E4@bneit.com" alt="[DIR]" /></td><td><a href="http://ppa.moosefs.com/moosefs-3/apt/ubuntu/precise/">precise/</a></td><td align="right">30-Nov-2016 18:42 </td><td align="right"> - </td><td> </td></tr><tr><td valign="top"><img src="cid:part8.252C9772.B02375E4@bneit.com" alt="[DIR]" /></td><td><a href="http://ppa.moosefs.com/moosefs-3/apt/ubuntu/quantal/">quantal/</a></td><td align="right">30-Nov-2016 18:42 </td><td align="right"> - </td><td> </td></tr><tr><td valign="top"><img src="cid:part8.252C9772.B02375E4@bneit.com" alt="[DIR]" /></td><td><a href="http://ppa.moosefs.com/moosefs-3/apt/ubuntu/trusty/">trusty/</a></td><td align="right">30-Nov-2016 18:42 </td><td align="right"> - </td><td> </td></tr></tbody></table> </div> </blockquote></div><br></div> |
|
From: WK <wk...@bn...> - 2016-12-24 00:52:53
|
Not seeing it in the repo mentioned on the website. Trusty (14) seems to work fine with a manual install. Any issues using that for just the mfsmount? Index of /moosefs-3/apt/ubuntu [ICO] Name <http://ppa.moosefs.com/moosefs-3/apt/ubuntu/?C=N;O=D> Last modified <http://ppa.moosefs.com/moosefs-3/apt/ubuntu/?C=M;O=A> Size <http://ppa.moosefs.com/moosefs-3/apt/ubuntu/?C=S;O=A> Description <http://ppa.moosefs.com/moosefs-3/apt/ubuntu/?C=D;O=A> ------------------------------------------------------------------------ [DIR] Parent Directory <http://ppa.moosefs.com/moosefs-3/apt/> - [DIR] lucid/ <http://ppa.moosefs.com/moosefs-3/apt/ubuntu/lucid/> 30-Nov-2016 18:42 - [DIR] maverick/ <http://ppa.moosefs.com/moosefs-3/apt/ubuntu/maverick/> 30-Nov-2016 18:42 - [DIR] precise/ <http://ppa.moosefs.com/moosefs-3/apt/ubuntu/precise/> 30-Nov-2016 18:42 - [DIR] quantal/ <http://ppa.moosefs.com/moosefs-3/apt/ubuntu/quantal/> 30-Nov-2016 18:42 - [DIR] trusty/ <http://ppa.moosefs.com/moosefs-3/apt/ubuntu/trusty/> 30-Nov-2016 18:42 - |
|
From: Aleksander W. <ale...@mo...> - 2016-12-14 09:45:45
|
Hi, Yes we remove few bugs in the latest MooseFS 3.0.86 This is latest changelog: 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) Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 12/14/2016 10:13 AM, Bernd Burg wrote: > > Hello, > > I am using mfs-pro to store virtual maschines in a Proxmox Cluster > > Worked perfekt until client 3.0.84. > > When i upgraded, i had a massive increase in I/O Delays on my servers. > After restart everything worked fine > > Then i read this threat an i downgraded my clients to 3.0.81 an that > solved the problem. > > > As i do not see anything new in the mail list on that item i would > like to know if 3.0.86 solves this problem now ? > > > > Mit freundlichen Grüßen > > > Bernd Burg > > ------------------------------------------------------------ > HOLDE AG > Zum Roppertsborn 14, 66646 Marpingen > > Telefon +49-6827-267988-0 > Telefax +49-6827-267988-9 > > Email b....@ho... <mailto:kr...@ac...> > > Sitz der Gesellschaft: Marpingen > AG Saarbrücken, HRB 101630 > > Ust-Id-Nr.: DE294620253 > > Vorstand: > Dipl.-Ing. Bernd Burg > > Aufsichtsrat: > Dipl.-Ing. Axel Gaus (Vorsitz) > Dipl.-Ing. Andreas Krolzig > > Dipl.-Ing. Gabor Richter > ------------------------------------------------------------ > > > Am 03.11.2016 um 18:09 schrieb Piotr Robert Konopelko: >> Great, >> >> thanks for the update! >> >> >> Best regards, >> Peter >> > > > > ------------------------------------------------------------------------------ > 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 |
84 messages has been excluded from this view by a project administrator.
