Menu
▾
▴
moosefs-users — Mailing list for MooseFS Users
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(20) |
Feb
(11) |
Mar
(11) |
Apr
(9) |
May
(22) |
Jun
(85) |
Jul
(94) |
Aug
(80) |
Sep
(72) |
Oct
(64) |
Nov
(69) |
Dec
(89) |
| 2011 |
Jan
(72) |
Feb
(109) |
Mar
(116) |
Apr
(117) |
May
(117) |
Jun
(102) |
Jul
(91) |
Aug
(72) |
Sep
(51) |
Oct
(41) |
Nov
(55) |
Dec
(74) |
| 2012 |
Jan
(45) |
Feb
(77) |
Mar
(99) |
Apr
(113) |
May
(132) |
Jun
(75) |
Jul
(70) |
Aug
(58) |
Sep
(58) |
Oct
(37) |
Nov
(51) |
Dec
(15) |
| 2013 |
Jan
(28) |
Feb
(16) |
Mar
(25) |
Apr
(38) |
May
(23) |
Jun
(39) |
Jul
(42) |
Aug
(19) |
Sep
(41) |
Oct
(31) |
Nov
(18) |
Dec
(18) |
| 2014 |
Jan
(17) |
Feb
(19) |
Mar
(39) |
Apr
(16) |
May
(10) |
Jun
(13) |
Jul
(17) |
Aug
(13) |
Sep
(8) |
Oct
(53) |
Nov
(23) |
Dec
(7) |
| 2015 |
Jan
(35) |
Feb
(13) |
Mar
(14) |
Apr
(56) |
May
(8) |
Jun
(18) |
Jul
(26) |
Aug
(33) |
Sep
(40) |
Oct
(37) |
Nov
(24) |
Dec
(20) |
| 2016 |
Jan
(38) |
Feb
(20) |
Mar
(25) |
Apr
(14) |
May
(6) |
Jun
(36) |
Jul
(27) |
Aug
(19) |
Sep
(36) |
Oct
(24) |
Nov
(15) |
Dec
(16) |
| 2017 |
Jan
(8) |
Feb
(13) |
Mar
(17) |
Apr
(20) |
May
(28) |
Jun
(10) |
Jul
(20) |
Aug
(3) |
Sep
(18) |
Oct
(8) |
Nov
|
Dec
(5) |
| 2018 |
Jan
(15) |
Feb
(9) |
Mar
(12) |
Apr
(7) |
May
(123) |
Jun
(41) |
Jul
|
Aug
(14) |
Sep
|
Oct
(15) |
Nov
|
Dec
(7) |
| 2019 |
Jan
(2) |
Feb
(9) |
Mar
(2) |
Apr
(9) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(12) |
Dec
(2) |
| 2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(18) |
Oct
(2) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(5) |
Oct
(5) |
Nov
(3) |
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael T. <mic...@ho...> - 2017-09-07 07:20:48
|
Hello! Last weekend, due to a building electrical issue, we had to power down all our servers. When we started the process to power down our chunkserver, "service moosefs-chunkerserver stop" took more than 30 minutes to complete. What could have caused this behavior? We'll need to power down our servers again this weekend for similar reason. What do I look for should this happen again? Is it safe to send SIGKILL signal if this happen again? Warm Regards, --- mike t. |
|
From: Marco M. <mar...@gm...> - 2017-08-29 22:46:27
|
Warren, I think the answer will depend on your hardware and configuration. -- Marco On 08/28/2017 04:26 PM, Warren Myers wrote: > What is the impact of replication rules on the raw IOPS you might otherwise see from just writing to the chunk servers as individual NFS > hosts (ie the performance impact of using the master server <-> chunk servers architecture)? > > > Do such metrics exist somewhere other than anecdotally? I've not found anything in the docs for this. > > > Thanks > > > > *Warren Myers* > https://antipaucity.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 > |
|
From: Warren M. <wa...@an...> - 2017-08-28 20:41:12
|
What is the impact of replication rules on the raw IOPS you might otherwise see from just writing to the chunk servers as individual NFS hosts (ie the performance impact of using the master server <-> chunk servers architecture)? Do such metrics exist somewhere other than anecdotally? I've not found anything in the docs for this. Thanks Warren Myers https://antipaucity.com |
|
From: Piotr R. K. <pio...@mo...> - 2017-08-02 18:08:24
|
Dear MooseFS Users, We are proud to announce, that MooseFS 3.0.97 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.97> as stable today! This version includes bugfixes and improves stability. If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! Please find the changes in MooseFS 3 since 3.0.94 below: MooseFS 3.0.97-1 (2017-08-01) (tools) fixed trash/sustained size desynchronization after file length changed by chunk creation (mount) fixed handling invalid arguments in posix lock command MooseFS 3.0.96-1 (2017-07-25) (tools) fixed segfault in mfsscadmin MooseFS 3.0.95-1 (2017-07-17) (mount+master) added update master version during reconnection to master (after updating master server) (master) fixed winattr field size in setattr command (mount) fixed dirattrcache (freezes or inefficiences during listing directories - introduced in 3.0.93) (cgi) fixed displaying master charts without leader (pro only) (mount) added info about using open dir cache in oplog/ophistory Best regards, Peter / MooseFS Team -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com <https://moosefs.com/> > On 4 Jul 2017, at 8:33 PM, Piotr Robert Konopelko <pio...@mo...> wrote: > > Dear MooseFS Users, > > We are proud to annonce, that MooseFS 3.0.94 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.94> as stable! > This version includes bugfixes and improves stability. > > If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! > > > Please find the changes in MooseFS 3 since 3.0.91 below: > MooseFS 3.0.94-1 (2017-06-22) > (mount) fixed support for CREATE/REPLACE flags in setxattr > (mount) added headers for flock defines > (all) added check for poll.h header file and use it instead of sys/poll.h if possible > (master) added test for WRITE access on directory during moving between different parents > (master) added clearing suig/sgid during write > (master+mount) increased max symlink path size to 4096(posix compliance) > > MooseFS 3.0.93-1 (2017-06-01) > (master) redesigned xattr storage (much faster and uses less memory) > (master) improved hash map in xattr and acl (static -> dynamic) > (cgi+cli) added possibility to define master group as set of IP adresses divided by comma or semicolon > (cs) fixed using fsync on closed descriptors (after change FSYNC_BEFORE_CLOSE option) > (master) fixed removing default acl > (master+mount) added support for basic Windows attributes (hidden, ro, system, archive) > (cgi+cli) fixed working with followers only > (all) added api for reading config parameters from master and chunkserver > (tools) increased timeout from 10 seconds to 20 seconds (needed for huge snapshots) > > MooseFS 3.0.92-1 (2017-04-27) > (master+tools) added chunk slices to mfsappendchunks > (tools) added archive mode tools > (master+mount) fixed getfacl (unnecessary check for read rights for uid/gid) > (master) fixed changing acl mask during setattr > > > Best regards, > Peter / MooseFS Team > > -- > Piotr Robert Konopelko | mobile: +48 601 476 440 > MooseFS Client Support Team | moosefs.com <https://moosefs.com/> >> On 10 Apr 2017, at 6:04 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >> >> Dear MooseFS Users, >> >> We are proud to annonce, that MooseFS 3.0.91 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.88> as stable! >> This version includes bugfixes and improves stability. >> >> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! >> >> >> Please find the changes in MooseFS 3 since 3.0.88 below: >> MooseFS 3.0.91-1 (2017-04-07) >> (all) silence false warnings generated by static analyzers (clang and cppcheck) >> (master) fixed quota testing routine used during move/rename >> (all) added README.md to distribution >> (cs+mount) decreased delay in conncache >> (mount) fixed reading done by many (20+) threads using one descriptor (premature removing requests from queue during cleaning) >> >> MooseFS 3.0.90-1 (2017-03-15) >> (master) fixed move/rename with quota >> (master) fixed chunk counters shown in cli/cgi >> (master+tools) added option preserve hardlinks to mfsmakesnapshot >> (master) fixed acl copying during mfsmakesnapshot >> >> MooseFS 3.0.89-1 (2017-02-21) >> (mount) added fixing file length in all inodes after write >> (cs) split bitfiled into separate bytes (fixed potential race condition) >> (master) setting operation to NONE before sending status (silence unnecessary messages in some cases) >> (cs) increased verbosity of crc-error messages >> (cs) fixed invalidating preserved block in case of truncate down followed by truncate up >> (mount) increased master-proxy buffer sizes >> >> >> >> Best regards, >> Peter / MooseFS Team >> >> -- >> Piotr Robert Konopelko >> MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> >>> On 9 Feb 2017, at 3:12 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>> >>> Dear MooseFS Users, >>> >>> We are proud to annonce, that MooseFS 3.0.88 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.88> as stable today! >>> This version includes bugfixes and improves stability (mainly concerning MooseFS Client). >>> >>> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! >>> >>> >>> Please find the changes in MooseFS 3 since 3.0.86 below: >>> MooseFS 3.0.88-1 (2017-02-08) >>> (mount) added read cache clean on write (same file access using different descriptors) >>> (mount) added missing cond_destroy in readdata.c (fix sent by Jakub Ratajczak) >>> (master) fixed initializing packet size for reading 'sustained' directory >>> (all) fixed zassert for printing correct statuses in case of pthread functions >>> >>> MooseFS 3.0.87-1 (2017-02-01) >>> (mount) fix fleng in finfo after truncate (patched by Davies Liu) >>> (mount) fix overlapped read (patched by Davies Liu) >>> (mount) fixed invalidating chunk cache after truncate >>> (mount) fixed fleng handling in read worker >>> (mount) fixed handling BREAK state in read worker >>> (mount) changed handling data invalidation in read module (sometimes could be less efficient, but it is much more safer) >>> (tools) fixed number parsing (patched by Pawel Gawronski) >>> (cli) fixed printed host/port options >>> (mount) moved pipes from requests to workers (read and write - huge decrease of descriptors used by mount) >>> (mount) changed signal to broadcast in rwlock (fixed very rare read/write deadlock) >>> (mount) fixed 'open descriptors' leak (lookup(with data for open)->open(with cached data)->close) >>> (mount) fixed potential 'race condition' - free csdata during access >>> (master) split (only internally) sustained folder into 256 subfolders (too many sustained files caused socket timeouts in master) >>> >>> >>> Best regards, >>> Peter / MooseFS Team >>> >>> -- >>> Piotr Robert Konopelko >>> MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> >>>> On 02 Dec 2016, at 7:54 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>> >>>> Dear MooseFS Users, >>>> >>>> we released the newest version MooseFS 3.0 recently: MooseFS 3.0.86. >>>> This version mainly contains bugfixes and improves stability. >>>> >>>> >>>> We strongly recommend to upgrade to the latest version, but please remember, that If you had version lower than 3.0.83 and then you upgraded your Chunkservers to v. 3.0.83 or higher, please DO NOT downgrade them! >>>> In MooseFS Chunkserver v. 3.0.83 we changed Chunk header from 5k to 8k (see changelog) - this is one of major changes and it means, that Chunkserver older than 3.0.83 cannot "understand" new Chunk header, which may lead to potential data loss! >>>> >>>> >>>> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Thanks! >>>> >>>> >>>> Please find the changes in MooseFS 3 since 3.0.77 below: >>>> MooseFS 3.0.86-1 (2016-11-30) >>>> (master) fixed leader-follower resynchronization after reconnection (pro only) >>>> (master) fixed rehashing condition in edge/node/chunk hashmaps (change inspired by yinjiawind) >>>> >>>> MooseFS 3.0.85-1 (2016-11-17) >>>> (mount) fixed memory leak (also efficiency) on Linux and potential segfaults on FreeBSD (negative condition) >>>> (mount) fixed race condition for inode value in write module >>>> (mount) better descriptors handling (lists of free elements) >>>> (mount) better releasing descriptors on FreeBSD >>>> (cs) fixed time condition (patch send by yinjiawind) >>>> >>>> MooseFS 3.0.84-1 (2016-10-06) >>>> (master) fixed setting acl-default without named users or named groups >>>> (master) fixed master-follower synchronization after setting storage class >>>> >>>> MooseFS 3.0.83-1 (2016-09-30) >>>> (cs) changed header size from 5k to 8k (due to 4k-sector hard disks) >>>> >>>> MooseFS 3.0.82-1 (2016-09-28) >>>> (all) silenced message about using deprecated parameter 'oom_adj' >>>> (mount) fixed FreeBSD delayed release mechanism >>>> (mount) added rwlock for chunks >>>> >>>> MooseFS 3.0.81-1 (2016-07-25) >>>> (mount) fixed oom killer disabling (setting oom_adj and oom_score_adj) >>>> (cli) fixed displaying inactive mounts >>>> (mount) added fsync before removing any locks >>>> (daemons) added disabling oom killer (Linux only) >>>> (all) small fixes in manpages >>>> (mount) fixed handling nonblocking lock commands (unlock and try) in both locking mechanisms >>>> (daemons+mount) changed default settings for limiting malloc arenas (Linux only) >>>> >>>> MooseFS 3.0.80-1 (2016-07-13) >>>> (master) fixed chunk loop (in some cases chunks from the last hash position might be left unchecked) >>>> (master) fixed storage class management (fixed has_***_labels fields) >>>> >>>> MooseFS 3.0.79-1 (2016-07-05) >>>> (master) fixed 'flock' (change type of lock SH->EX and EX->SH caused access to freed memory and usually SEGV) >>>> >>>> MooseFS 3.0.78-1 (2016-06-14) >>>> (cs) fixed serious error that may cause data corruption during internal rebalance (intr. in 3.0.75) >>>> >>>> >>>> >>>> Best regards, >>>> Peter >>>> >>>> -- >>>> >>>> <https://moosefs.com/>Piotr Robert Konopelko >>>> MooseFS Technical Support Engineer >>>> e-mail: pio...@mo... <mailto:pio...@mo...> >>>> www: https://moosefs.com <https://moosefs.com/> >>>> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> >>>> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. >>>> >>>> >>>>> On 08 Jun 2016, at 1:04 AM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>>> >>>>> Dear MooseFS Users, >>>>> >>>>> we released the newest versions of both MooseFS 3.0 and MooseFS 2.0 recently: 3.0.77 and 2.0.89. >>>>> >>>>> They improve MooseFS stability and (in MooseFS 3.0) also add new features, like: >>>>> Storage Classes <https://moosefs.com/documentation/moosefs-3-0.html> >>>>> Possibility to mount MooseFS on Linux by issuing: mount -t moosefs mfsmaster.example.lan: /mnt/mfs >>>>> File sparsification >>>>> Automatic temporary maintenance mode >>>>> New I/O synchronisation between different mounts >>>>> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Thanks! >>>>> >>>>> >>>>> Please find the changes in MooseFS 3 since 3.0.73 below: >>>>> MooseFS 3.0.77-1 (2016-06-07) >>>>> (mount) added assertions after packet allocation in master communication module >>>>> (manpages) fixes related to storage classes >>>>> (all) improved error messages used for storage classes >>>>> >>>>> MooseFS 3.0.76-1 (2016-06-03) >>>>> (master) fixed resolving multi path for root inode >>>>> (master) fixed licence expiration behaviour (pro only) >>>>> >>>>> MooseFS 3.0.75-1 (2016-04-20) >>>>> (all) fixed cppcheck warnings/errors (mostly false negatives) >>>>> (cs) added file sparsification during chunk write (also chunk replication, chunk duplication etc.) >>>>> (mount) fixed write data inefficiency when I/O was performed by root >>>>> (master) fixed removing too early locked chunks from data structures >>>>> (tools) fixed reusing local ports (connection to master returned EADDRNOTAVAIL) >>>>> (all) changed default action from restart to start >>>>> (all) added exiting when user defined config (option -c) cannot be loaded >>>>> (cs) changed handling chunk filename (dynamic filename generation - cs should use less memory) >>>>> (netdump) changed 'moose ports only' option to 'port range' >>>>> (mount) limited number of files kept as open after close >>>>> (cs) changed subfolder choosing algorithm >>>>> (mount) changed mutex lock to rw-lock for I/O on the same descriptor >>>>> (mount) added link to mfsmount from '/sbin/mount.moosefs' (Linux only) >>>>> (all) introduced "storage classes" (new goal/labels management) >>>>> (master+cs) introduced 'temporary maintenance mode' (automatic maintenance mode after graceful stop of cs) >>>>> (master+mount) added fix for bug in FreeBSD kernel (kernel sends truncate before first close - FreeBSD only) >>>>> (cs) fixed setting malloc pools on Linux >>>>> >>>>> MooseFS 3.0.74-1 (2016-03-08) >>>>> (master) fixed rebalance replication (check for all chunk copies for destination - not only valid) >>>>> (master+mount) new mechanism for atime+mtime setting during I/O >>>>> (master+mount) new I/O synchronization between different mounts (with cache invalidation) >>>>> (master+mount) new chunk number/version cache (with automatic invalidation from master) >>>>> (master) added mapping chunkserver IP classes (allow to have separate network for I/O and separate for other activity) >>>>> (master) fixed status returned by writechunk after network down/up >>>>> (master) changed trashtime from seconds to hours >>>>> (master) added METADATA_SAVE_FREQ option (allow to save metadata less frequently than every hour) >>>>> (master) added using in emergency (endangered chunks) all available servers for replication (even overloaded and being maintained) >>>>> (master) added using chunkservers in 'internal rebalance' state in case of deleting chunks >>>>> (all) spell check errors fixed (patch contributed by Dmitry Smirnov) >>>>> >>>>> Please find the changes in MooseFS 2.0 since 2.0.88 below: >>>>> MooseFS 2.0.89-1 (2016-04-27) >>>>> (master+mount) added fix for bug in FreeBSD kernel (kernel sends truncate before first close - FreeBSD only) >>>>> >>>>> Best regards, >>>>> >>>>> -- >>>>> >>>>> <Mail Attachment.png> <https://moosefs.com/> >>>>> >>>>> Piotr Robert Konopelko >>>>> MooseFS Technical Support Engineer >>>>> e-mail : pio...@mo... <mailto:pio...@mo...> >>>>> www : https://moosefs.com <https://moosefs.com/> >>>>> >>>>> <Mail Attachment.png> <https://twitter.com/MooseFS><Mail Attachment.png> <https://www.facebook.com/moosefs><Mail Attachment.png> <https://www.linkedin.com/company/moosefs><Mail Attachment.png> <https://github.com/moosefs> >>>>> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. >>>>> >>>>> >>>>>> On 08 Mar 2016, at 9:24 AM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>>>> >>>>>> Dear MooseFS Users, >>>>>> >>>>>> we released the newest versions of both MooseFS 3 and MooseFS 2 recently: 3.0.73 and 2.0.88. >>>>>> >>>>>> Please find the changes in MooseFS 3 since 3.0.71 below: >>>>>> >>>>>> MooseFS 3.0.73-1 (2016-02-11) >>>>>> (master) fixed restoring ARCHCHG from changelog >>>>>> (cli+cgi) fixed displaying master list with followers only (pro version only) >>>>>> (master) added using size and length quota to fix disk usage values (statfs) >>>>>> (master) fixed xattr bug which may lead to data corruption and segfaults (intr. in 2.1.1) >>>>>> (master) added 'node_info' packet >>>>>> (tools) added '-p' option to 'mfsdirinfo' - 'precise mode' >>>>>> (master) fixed edge renumeration >>>>>> (master) added detecting of wrong edge numbers and force renumeration in such case >>>>>> >>>>>> MooseFS 3.0.72-1 (2016-02-04) >>>>>> (master+cgi+cli) added global 'umask' option to exports.cfg >>>>>> (all) changed address of FSF in GPL licence text >>>>>> (debian) removed obsolete conffiles >>>>>> (debian) fixed copyright file >>>>>> (mount) fixed parsing mfsmount.cfg (system options like nodev,noexec etc. were ommited) >>>>>> (master) changed way how cs internal rebalance state is treated by master (as 'grace' state instead of 'overloaded') >>>>>> (mount) fixed bug in read module (setting etab after ranges realloc) >>>>>> (tools) removed obsoleted command 'mfssnapshot' >>>>>> >>>>>> >>>>>> Please find the changes in MooseFS 2 since 2.0.83 below: >>>>>> >>>>>> MooseFS 2.0.88-1 (2016-03-02) >>>>>> (master) added METADATA_SAVE_FREQ option (allow to save metadata less frequently than every hour) >>>>>> >>>>>> MooseFS 2.0.87-1 (2016-02-23) >>>>>> (master) fixed status returned by writechunk after network down/up >>>>>> >>>>>> MooseFS 2.0.86-1 (2016-02-22) >>>>>> (master) fixed initialization of ATIME_MODE >>>>>> >>>>>> MooseFS 2.0.85-1 (2016-02-11) >>>>>> (master) added ATIME_MODE option to set atime modification behaviour >>>>>> (master) added using size and length quota to fix disk usage values (statfs) >>>>>> (all) changed address of FSF in GPL licence text >>>>>> (debian) removed obsolete conffiles >>>>>> (debian) fixed copyright file >>>>>> (mount) fixed parsing mfsmount.cfg (system options like nodev,noexec etc. were ommited) >>>>>> (tools) removed obsoleted command 'mfssnapshot' >>>>>> >>>>>> MooseFS 2.0.84-1 (2016-01-19) >>>>>> (mount) fixed setting file length in write module during truncate (fixes "git svn" case) >>>>>> >>>>>> Best regards, >>>>>> >>>>>> -- >>>>>> >>>>>> <Mail Attachment.png> <https://moosefs.com/> >>>>>> >>>>>> Piotr Robert Konopelko >>>>>> MooseFS Technical Support Engineer >>>>>> e-mail : pio...@mo... <mailto:pio...@mo...> >>>>>> www : https://moosefs.com <https://moosefs.com/> >>>>>> >>>>>> <Mail Attachment.png> <https://twitter.com/MooseFS><Mail Attachment.png> <https://www.facebook.com/moosefs><Mail Attachment.png> <https://www.linkedin.com/company/moosefs><Mail Attachment.png> <https://github.com/moosefs> >>>>>> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. >>>>>> >>>>>> >>>>>>> On 27 Jan 2016, at 5:51 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>>>>> >>>>>>> Dear MooseFS Users, >>>>>>> >>>>>>> today we published the newest version from 3.x branch: 3.0.71. >>>>>>> >>>>>>> Please find the changes since 3.0.69 below: >>>>>>> >>>>>>> MooseFS 3.0.71-1 (2016-01-21) >>>>>>> (master) fixed emptying trash issue (intr. in 3.0.64) >>>>>>> (master) fixed possible segfault in chunkservers database (intr. in 3.0.67) >>>>>>> (master) changed trash part choice from nondeterministic to deterministic >>>>>>> >>>>>>> MooseFS 3.0.70-1 (2016-01-19) >>>>>>> (cgi+cli) fixed displaying info when there are no active masters (intr. in 3.0.67) >>>>>>> (mount+common) refactoring code to be Windows ready >>>>>>> (mount) added option 'mfsflattrash' (makes trash look like before version 3.0.64) >>>>>>> (mount) added fixes for NetBSD (patch contributed by Tom Ivar Helbekkmo) >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> -- >>>>>>> Piotr Robert Konopelko >>>>>>> MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot_________________________________________ <http://sdm.link/slashdot_________________________________________> >> moosefs-users mailing list >> moo...@li... <mailto:moo...@li...> >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Aleksander W. <ale...@mo...> - 2017-07-27 08:58:19
|
Hi. Thank you for all this information. Right now all should be fine. By the way. We recommend to use MooseFS github for project source code. https://github.com/moosefs/moosefs Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 26.07.2017 20:56, Alex Crow wrote: > > > On 26/07/17 19:10, Mariusz Paradowski via moosefs-users wrote: >> On Wed, 26 Jul 2017 07:16:42 +0000, >> in >> DM5...@DM..., >> >> Michael Tinsay <mic...@ho...> wrote: >> >>> The download links for the sources at >>> https://moosefs.com/download/sources.html ask for login >>> credentials. Is >>> this a new thing? I do not recall being asked when I downloaded >>> before. >> >> Confirmed: >> >> $ curl -k -I https://ppa.moosefs.com/src/moosefs-3.0.94-1.tar.gz >> HTTP/1.1 401 Authorization Required >> Date: Wed, 26 Jul 2017 18:03:57 GMT >> Server: Apache >> Strict-Transport-Security: max-age=15768000; includeSubDomains; preload >> WWW-Authenticate: Basic realm="By Invitation Only" >> Vary: Accept-Encoding >> Content-Type: text/html; charset=iso-8859-1 >> >> >> It works with plain HTTP: >> >> $ curl -I http://ppa.moosefs.com/src/moosefs-3.0.94-1.tar.gz >> HTTP/1.1 200 OK >> Date: Wed, 26 Jul 2017 18:08:20 GMT >> Server: Apache >> Last-Modified: Sun, 02 Jul 2017 20:57:55 GMT >> ETag: "2067aba-110286-5535be78a0d87" >> Accept-Ranges: bytes >> Content-Length: 1114758 >> Content-Type: application/x-gzip > > Firefox has no problem on the webpage for current or archive sources, > but that only offers http URIs. HTTPS does seem to want auth, so > verified here too. Only affects HTTPS. > > Cheers > > Alex |
|
From: Alex C. <ac...@in...> - 2017-07-26 19:21:18
|
On 26/07/17 19:10, Mariusz Paradowski via moosefs-users wrote: > On Wed, 26 Jul 2017 07:16:42 +0000, > in > DM5...@DM..., > Michael Tinsay <mic...@ho...> wrote: > >> The download links for the sources at >> https://moosefs.com/download/sources.html ask for login credentials. Is >> this a new thing? I do not recall being asked when I downloaded before. > > Confirmed: > > $ curl -k -I https://ppa.moosefs.com/src/moosefs-3.0.94-1.tar.gz > HTTP/1.1 401 Authorization Required > Date: Wed, 26 Jul 2017 18:03:57 GMT > Server: Apache > Strict-Transport-Security: max-age=15768000; includeSubDomains; preload > WWW-Authenticate: Basic realm="By Invitation Only" > Vary: Accept-Encoding > Content-Type: text/html; charset=iso-8859-1 > > > It works with plain HTTP: > > $ curl -I http://ppa.moosefs.com/src/moosefs-3.0.94-1.tar.gz > HTTP/1.1 200 OK > Date: Wed, 26 Jul 2017 18:08:20 GMT > Server: Apache > Last-Modified: Sun, 02 Jul 2017 20:57:55 GMT > ETag: "2067aba-110286-5535be78a0d87" > Accept-Ranges: bytes > Content-Length: 1114758 > Content-Type: application/x-gzip Firefox has no problem on the webpage for current or archive sources, but that only offers http URIs. HTTPS does seem to want auth, so verified here too. Only affects HTTPS. Cheers Alex -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. This email is not intended to, nor should it be taken to, constitute advice. The information provided is correct to our knowledge & belief and must not be used as a substitute for obtaining tax, regulatory, investment, legal or any other appropriate advice. "Transact" is operated by Integrated Financial Arrangements Ltd. 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. (Registered office: as above; Registered in England and Wales under number: 3727592). Authorised and regulated by the Financial Conduct Authority (entered on the Financial Services Register; no. 190856). |
|
From: Mariusz P. <m.p...@sy...> - 2017-07-26 18:25:36
|
On Wed, 26 Jul 2017 07:16:42 +0000, in DM5...@DM..., Michael Tinsay <mic...@ho...> wrote: > The download links for the sources at > https://moosefs.com/download/sources.html ask for login credentials. Is > this a new thing? I do not recall being asked when I downloaded before. Confirmed: $ curl -k -I https://ppa.moosefs.com/src/moosefs-3.0.94-1.tar.gz HTTP/1.1 401 Authorization Required Date: Wed, 26 Jul 2017 18:03:57 GMT Server: Apache Strict-Transport-Security: max-age=15768000; includeSubDomains; preload WWW-Authenticate: Basic realm="By Invitation Only" Vary: Accept-Encoding Content-Type: text/html; charset=iso-8859-1 It works with plain HTTP: $ curl -I http://ppa.moosefs.com/src/moosefs-3.0.94-1.tar.gz HTTP/1.1 200 OK Date: Wed, 26 Jul 2017 18:08:20 GMT Server: Apache Last-Modified: Sun, 02 Jul 2017 20:57:55 GMT ETag: "2067aba-110286-5535be78a0d87" Accept-Ranges: bytes Content-Length: 1114758 Content-Type: application/x-gzip -- Mariusz Paradowski System & Network Administrator MP7509-RIPE +48606393521 |
|
From: Aleksander W. <ale...@mo...> - 2017-07-26 07:49:53
|
Hi. No we don't set any authentication for MooseFS source and we are not planning to do such a thing. Would you be so kind end send us this link? Maybe you have PROXY server inside your LAN. By the way, we are able to download source code without any problems. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 26.07.2017 09:16, Michael Tinsay wrote: > Hi. > > > The download links for the sources > at https://moosefs.com/download/sources.html ask for login > credentials. Is this a new thing? I do not recall being asked when I > downloaded before. > > > > --- mike t. > |
|
From: Michael T. <mic...@ho...> - 2017-07-26 07:16:55
|
Hi. The download links for the sources at https://moosefs.com/download/sources.html ask for login credentials. Is this a new thing? I do not recall being asked when I downloaded before. --- mike t. |
|
From: <ma...@me...> - 2017-07-19 14:06:52
|
W dniu 18.07.2017 o 09:02, Aleksander Wieliczko pisze: > Hi. > I would like to inform you that we have found source of the problem. > Probably today we will publish new version. > > Thank you for all your help. Hi! # time du -hs /mnt/mfs/dir 695G /mnt/mfs/w2t-www/ real 3m48.571s user 0m5.856s sys 0m24.992s # find /mnt/mfs/dir/ -type f |wc -l 594102 It took sometime but it finished. Thank you for very quick fix! Marcin |
|
From: Aleksander W. <ale...@mo...> - 2017-07-19 12:32:10
|
Hi. I would like to inform you that new version 3.0.95 is available. We have removed rare bug connected with dir cache. W strongly advise to update MosoeFS to latest version. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com |
|
From: Aleksander W. <ale...@mo...> - 2017-07-18 07:02:54
|
Hi. I would like to inform you that we have found source of the problem. Probably today we will publish new version. Thank you for all your help. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> |
|
From: <ma...@me...> - 2017-07-14 08:20:53
|
W dniu 14.07.2017 o 09:01, Aleksander Wieliczko pisze: > Hi Marcin. Hi! > Would you be so kind and tell us something more about your files > permissions. > Do you have some ACL's or xattr's set on files? I'm using ACL, XATTR are not used. Files are owned by a couple of users. I run `getfattr -dR //mnt/mfs/` on monted fs (client in 3.0.94) and it also triggered mentioned problem. > Do you have different MooseFS clientes working in your cluster than 3.0.94? Yes but other clients works on separated directory, other clients are in 3.0.91 or 3.0.92, > And one more question. > Are you able to reproduce this problem on MooseFS client in version 3.0.92? No, on 3.0.92 `du -hs` finished without problem. fuse is in 2.9.7. Marcin |
|
From: Aleksander W. <ale...@mo...> - 2017-07-14 07:01:16
|
Hi Marcin. Would you be so kind and tell us something more about your files permissions. Do you have some ACL's or xattr's set on files? Do you have different MooseFS clientes working in your cluster than 3.0.94? And one more question. Are you able to reproduce this problem on MooseFS client in version 3.0.92? Thanks, Alex |
|
From: <ma...@me...> - 2017-07-13 12:49:53
|
W dniu 12.07.2017 o 20:03, WK pisze: > > > On 7/11/2017 6:23 AM, David Myer via moosefs-users wrote: >> Hi, >> >> >> >> Not sure if this relates but I have had problems with rsync hanging >> when transferring to an MFS mount due to not enough chunkserver workers. >> >> > > I had a similiar problem when a single 'new' chunkserver had a bad > netmask and was unreachable from the client, but available to the > master. The other chunkservers and the master were reachable. > The rsync just 'hung' and I couldn't kill it. I saw the error in the > log, fixed the netmask on the new chunker and everything immediately > cleared up. Hi! I found that it's enough when I run `du -hs` on fs with thousands of small files to reproduce it. Rsync process didn't trigger the bug. Marcin |
|
From: WK <wk...@bn...> - 2017-07-12 18:03:15
|
On 7/11/2017 6:23 AM, David Myer via moosefs-users wrote: > Hi, > > > > Not sure if this relates but I have had problems with rsync hanging > when transferring to an MFS mount due to not enough chunkserver workers. > > I had a similiar problem when a single 'new' chunkserver had a bad netmask and was unreachable from the client, but available to the master. The other chunkservers and the master were reachable. The rsync just 'hung' and I couldn't kill it. I saw the error in the log, fixed the netmask on the new chunker and everything immediately cleared up. |
|
From: <ma...@me...> - 2017-07-11 13:39:55
|
W dniu 11.07.2017 o 15:23, David Myer pisze: > Hi, > > You could try to determine what processes are using the disk, and then > try and kill them: > > fuser /mnt/mfs/mfs-filesystem > lsof /mnt/mfs/mfs-filesystem > > Not sure if this relates but I have had problems with rsync hanging when > transferring to an MFS mount due to not enough chunkserver workers. Hi, thanks for reply. Unfortunately I can't kill any process using mfs fs nor mfs mount. After sending -9 to mfs mount it stays in Z state and is <defunct>. fusermount -u neither can't umount fs: fusermount: failed to unmount /mnt/mfs: Device or resource busy Marcin |
|
From: David M. <dav...@pr...> - 2017-07-11 13:23:25
|
Hi,
You could try to determine what processes are using the disk, and then try and kill them:
fuser /mnt/mfs/mfs-filesystem
lsof /mnt/mfs/mfs-filesystem
Not sure if this relates but I have had problems with rsync hanging when transferring to an MFS mount due to not enough chunkserver workers.
Cheers,
Dave
> -------- Original Message --------
> Subject: [MooseFS-Users] mfsmount stuck
> Local Time: July 11, 2017 3:29 AM
> UTC Time: July 11, 2017 7:29 AM
> From: ma...@me...
> To: MooseFS-Users <moo...@li...>
> Hi!
> I"ve experienced mfs.mount stuck while doing intensive I/O operations with many small files. I run two operations, rsync -avS /local/fs/with/thousands/of/files /mnt/mfs/mfs-filesystem/ , rsync was copying files for long time and there was no problem. Next I run du -hs /mnt/mfs/mfs-filesystem (parallelly to rsync) and after a minute or two mfs.mount stuck.
> mfsnetdump shows:
> 1499757977.093449 : 192.168.100.190 : 26157 -> 192.168.100. 10 : 9421 CLTOMA_FUSE_STATFS
> 0x00000: 00 00 00 12
> 1499757977.093585 : 192.168.100. 10 : 9421 -> 192.168.100.190 : 26157 MATOCL_FUSE_STATFS
> 0x00000: 00 00 00 12 00 00 01 AA 9A 4B 20 00 00 00 01 35 DB 1B 24 00 00 00 00 00 00 00 00 4E 00 00 00 00
> 0x00020: 00 00 00 00 00 04 E2 89
> 1499757987.734365 : 192.168.100.190 : 26157 -> 192.168.100. 10 : 9421 CLTOMA_FUSE_SUSTAINED_INODES
> 0x00000: 00 00 6F 89 00 04 E2 8A
> 1499758005.736338 : 192.168.100.190 : 26157 -> 192.168.100. 10 : 9421 CLTOMA_FUSE_TIME_SYNC
> 0x00000: 00 00 00 00
> 1499758005.736455 : 192.168.100. 10 : 9421 -> 192.168.100.190 : 26157 MATOCL_FUSE_TIME_SYNC
> 0x00000: 00 00 00 00 00 05 54 05 9F 2E 52 8D
> strace shows:
> [pid 31457] 09:28:17.274753 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.277375 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
> [pid 31470] 09:28:17.278169 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
> [pid 31470] 09:28:17.278189 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
> [pid 31457] 09:28:17.279987 <... nanosleep resumed> 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.280028 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.282634 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.285247 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.287876 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
> [pid 31470] 09:28:17.288265 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
> [pid 31470] 09:28:17.288290 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
> [pid 31457] 09:28:17.290498 <... nanosleep resumed> 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.290532 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.293154 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.295804 read(31, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.295853 write(31, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.295906 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
> [pid 31470] 09:28:17.298369 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
> [pid 31470] 09:28:17.298388 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
> [pid 31457] 09:28:17.298487 <... nanosleep resumed> 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.298507 read(38, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.298535 write(38, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.298566 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.301151 read(13, 0x7ff9e3758f20, 8) = -1 EAGAIN (Resource temporarily unavailable)
> [pid 31457] 09:28:17.301184 write(13, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.301217 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.303805 read(18, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.303846 write(18, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.303885 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.306513 read(28, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.306545 write(28, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.306572 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
> [pid 31470] 09:28:17.308463 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
> [pid 31470] 09:28:17.308481 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
> [pid 31457] 09:28:17.309149 <... nanosleep resumed> 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.309166 read(19, 0x7ff9e3758f20, 8) = -1 EAGAIN (Resource temporarily unavailable)
> [pid 31457] 09:28:17.309191 write(19, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.309218 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.311812 read(25, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.311860 write(25, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.311904 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.314511 read(34, 0x7ff9e3758f20, 8) = -1 EAGAIN (Resource temporarily unavailable)
> [pid 31457] 09:28:17.314544 write(34, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.314578 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.317166 read(22, 0x7ff9e3758f20, 8) = -1 EAGAIN (Resource temporarily unavailable)
> [pid 31457] 09:28:17.317194 write(22, "\0\0\0\0\0\0\0\0", 8) = 8
> [pid 31457] 09:28:17.317226 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
> [pid 31470] 09:28:17.318560 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
> [pid 31470] 09:28:17.318582 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
> [pid 31457] 09:28:17.319824 <... nanosleep resumed> 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.319853 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
> [pid 31472] 09:28:17.320388 <... nanosleep resumed> 0x7ff9d09b5f20) = 0
> [pid 31472] 09:28:17.320420 nanosleep({tv_sec=0, tv_nsec=100000000}, <unfinished ...>
> [pid 31457] 09:28:17.322446 <... nanosleep resumed> 0x7ff9e3758f10) = 0
> [pid 31457] 09:28:17.322469 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
> At this moment I can"t do any I/O operation on this mountpoint.
> All moosefs components are 3.0.94.
> Thanks for help,
> Marcin
> ------------------------------------------------------------------------------
> 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: <ma...@me...> - 2017-07-11 07:30:51
|
Hi!
I've experienced mfs.mount stuck while doing intensive I/O operations with many small files. I run two operations, rsync -avS /local/fs/with/thousands/of/files /mnt/mfs/mfs-filesystem/ , rsync was copying files for long time and there was no problem. Next I run du -hs /mnt/mfs/mfs-filesystem (parallelly to rsync) and after a minute or two mfs.mount stuck.
mfsnetdump shows:
1499757977.093449 : 192.168.100.190 : 26157 -> 192.168.100. 10 : 9421 CLTOMA_FUSE_STATFS
0x00000: 00 00 00 12
1499757977.093585 : 192.168.100. 10 : 9421 -> 192.168.100.190 : 26157 MATOCL_FUSE_STATFS
0x00000: 00 00 00 12 00 00 01 AA 9A 4B 20 00 00 00 01 35 DB 1B 24 00 00 00 00 00 00 00 00 4E 00 00 00 00
0x00020: 00 00 00 00 00 04 E2 89
1499757987.734365 : 192.168.100.190 : 26157 -> 192.168.100. 10 : 9421 CLTOMA_FUSE_SUSTAINED_INODES
0x00000: 00 00 6F 89 00 04 E2 8A
1499758005.736338 : 192.168.100.190 : 26157 -> 192.168.100. 10 : 9421 CLTOMA_FUSE_TIME_SYNC
0x00000: 00 00 00 00
1499758005.736455 : 192.168.100. 10 : 9421 -> 192.168.100.190 : 26157 MATOCL_FUSE_TIME_SYNC
0x00000: 00 00 00 00 00 05 54 05 9F 2E 52 8D
strace shows:
[pid 31457] 09:28:17.274753 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.277375 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
[pid 31470] 09:28:17.278169 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
[pid 31470] 09:28:17.278189 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
[pid 31457] 09:28:17.279987 <... nanosleep resumed> 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.280028 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.282634 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.285247 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.287876 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
[pid 31470] 09:28:17.288265 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
[pid 31470] 09:28:17.288290 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
[pid 31457] 09:28:17.290498 <... nanosleep resumed> 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.290532 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.293154 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.295804 read(31, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.295853 write(31, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.295906 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
[pid 31470] 09:28:17.298369 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
[pid 31470] 09:28:17.298388 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
[pid 31457] 09:28:17.298487 <... nanosleep resumed> 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.298507 read(38, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.298535 write(38, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.298566 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.301151 read(13, 0x7ff9e3758f20, 8) = -1 EAGAIN (Resource temporarily unavailable)
[pid 31457] 09:28:17.301184 write(13, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.301217 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.303805 read(18, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.303846 write(18, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.303885 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.306513 read(28, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.306545 write(28, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.306572 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
[pid 31470] 09:28:17.308463 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
[pid 31470] 09:28:17.308481 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
[pid 31457] 09:28:17.309149 <... nanosleep resumed> 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.309166 read(19, 0x7ff9e3758f20, 8) = -1 EAGAIN (Resource temporarily unavailable)
[pid 31457] 09:28:17.309191 write(19, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.309218 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.311812 read(25, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.311860 write(25, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.311904 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.314511 read(34, 0x7ff9e3758f20, 8) = -1 EAGAIN (Resource temporarily unavailable)
[pid 31457] 09:28:17.314544 write(34, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.314578 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.317166 read(22, 0x7ff9e3758f20, 8) = -1 EAGAIN (Resource temporarily unavailable)
[pid 31457] 09:28:17.317194 write(22, "\0\0\0\0\0\0\0\0", 8) = 8
[pid 31457] 09:28:17.317226 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
[pid 31470] 09:28:17.318560 <... nanosleep resumed> 0x7ff9d14d9f00) = 0
[pid 31470] 09:28:17.318582 nanosleep({tv_sec=0, tv_nsec=10000000}, <unfinished ...>
[pid 31457] 09:28:17.319824 <... nanosleep resumed> 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.319853 nanosleep({tv_sec=0, tv_nsec=2500000}, <unfinished ...>
[pid 31472] 09:28:17.320388 <... nanosleep resumed> 0x7ff9d09b5f20) = 0
[pid 31472] 09:28:17.320420 nanosleep({tv_sec=0, tv_nsec=100000000}, <unfinished ...>
[pid 31457] 09:28:17.322446 <... nanosleep resumed> 0x7ff9e3758f10) = 0
[pid 31457] 09:28:17.322469 nanosleep({tv_sec=0, tv_nsec=2500000}, 0x7ff9e3758f10) = 0
At this moment I can't do any I/O operation on this mountpoint.
All moosefs components are 3.0.94.
Thanks for help,
Marcin
|
|
From: <ma...@me...> - 2017-07-06 12:04:48
|
W dniu 06.07.2017 o 13:04, Piotr Robert Konopelko pisze: > Cześć Marcin, > >> There is free space on filesystem. mfshdd has one line: >> </var/lib/mfs/chunks -5GiB > > > If you use "lower than" mark before HDD path, it is an indication for Chunkserver, that it should move out all the chunks from this HDD to other, but *on the same server* (please read comments in /etc/mfs/mfshdd.cfg carefully). And this mark prevents Chunkserver for storing new chunks on the particular mountpoint. As You have only one HDD on this server, it is impossible to use others (because they don't exist). > > Just remove "<" and everything should be back to normal. Thank you Piotr for help. Now I recoll what I mean when I created such configuration. I wanted this chunk server to has as low priority as it is possible, I wanted this chunkserver to be used only when no more other chunkservers would be available. Dzięki. |
|
From: Piotr R. K. <pio...@mo...> - 2017-07-06 11:04:44
|
Cześć Marcin, > There is free space on filesystem. mfshdd has one line: > </var/lib/mfs/chunks -5GiB If you use "lower than" mark before HDD path, it is an indication for Chunkserver, that it should move out all the chunks from this HDD to other, but *on the same server* (please read comments in /etc/mfs/mfshdd.cfg carefully). And this mark prevents Chunkserver for storing new chunks on the particular mountpoint. As You have only one HDD on this server, it is impossible to use others (because they don't exist). Just remove "<" and everything should be back to normal. Best regards, Peter -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com > On 6 Jul 2017, at 12:18 PM, ma...@me... wrote: > > Hello! > I noticed that syslog is flooded with messages like below: > > Jul 6 06:25:23 foo mfschunkserver[2448]: replicator: hdd_create status: No space left > Jul 6 06:25:23 foo mfschunkserver[2448]: message repeated 3 times: [ replicator: hdd_create status: No space left] > Jul 6 06:25:23 foo mfsmaster[2452]: (192.168.100.11:9422 -> 192.168.100.10:9422) chunk: 00000000000071BB replication status: No space left > Jul 6 06:25:23 foo mfsmaster[2452]: (192.168.100.11:9422 -> 192.168.100.10:9422) chunk: 0000000000002BBA replication status: No space left > Jul 6 06:25:23 foo mfsmaster[2452]: (192.168.100.11:9422 -> 192.168.100.10:9422) chunk: 0000000000004893 replication status: No space left > Jul 6 06:25:23 foo mfsmaster[2452]: (192.168.100.11:9422 -> 192.168.100.10:9422) chunk: 00000000000053A8 replication status: No space left > > There is free space on filesystem. mfshdd has one line: > </var/lib/mfs/chunks -5GiB > > # df -Th /var//lib/mfs/ > Filesystem Type Size Used Avail Use% Mounted on > /dev/mapper/w2t--cl--a--00--vg-mfs--storage xfs 50G 108M 50G 1% /var/lib/mfs > > # du -hs /var/lib/mfs/chunks > 16K /var/lib/mfs/chunks > > mfsmaster is 3.0.94. > What can be a reason of this messages? > > Marcin > > ------------------------------------------------------------------------------ > 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: <ma...@me...> - 2017-07-06 10:19:48
|
Hello! I noticed that syslog is flooded with messages like below: Jul 6 06:25:23 foo mfschunkserver[2448]: replicator: hdd_create status: No space left Jul 6 06:25:23 foo mfschunkserver[2448]: message repeated 3 times: [ replicator: hdd_create status: No space left] Jul 6 06:25:23 foo mfsmaster[2452]: (192.168.100.11:9422 -> 192.168.100.10:9422) chunk: 00000000000071BB replication status: No space left Jul 6 06:25:23 foo mfsmaster[2452]: (192.168.100.11:9422 -> 192.168.100.10:9422) chunk: 0000000000002BBA replication status: No space left Jul 6 06:25:23 foo mfsmaster[2452]: (192.168.100.11:9422 -> 192.168.100.10:9422) chunk: 0000000000004893 replication status: No space left Jul 6 06:25:23 foo mfsmaster[2452]: (192.168.100.11:9422 -> 192.168.100.10:9422) chunk: 00000000000053A8 replication status: No space left There is free space on filesystem. mfshdd has one line: </var/lib/mfs/chunks -5GiB # df -Th /var//lib/mfs/ Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/w2t--cl--a--00--vg-mfs--storage xfs 50G 108M 50G 1% /var/lib/mfs # du -hs /var/lib/mfs/chunks 16K /var/lib/mfs/chunks mfsmaster is 3.0.94. What can be a reason of this messages? Marcin |
|
From: Michael S. <mas...@li...> - 2017-07-05 09:08:23
|
Hi! I had installation of MooseFS 2, which includes one master, two chunk-server, three metaloger-server on Centos 6 with total disk size 41TB. I provide disk space for windows clients with samba. The day before yesterday i upgraded to version 3.0 and I have a problem with samba clients. File access is slow or does not work. As a workaround I rolled back mfsmount to version 2.0 and it worked. Please help to solve the problem. Sincerely, Michael Suhanov mas...@li... |
|
From: Piotr R. K. <pio...@mo...> - 2017-07-04 18:33:26
|
Dear MooseFS Users, We are proud to annonce, that MooseFS 3.0.94 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.94> as stable! This version includes bugfixes and improves stability. If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! Please find the changes in MooseFS 3 since 3.0.91 below: MooseFS 3.0.94-1 (2017-06-22) (mount) fixed support for CREATE/REPLACE flags in setxattr (mount) added headers for flock defines (all) added check for poll.h header file and use it instead of sys/poll.h if possible (master) added test for WRITE access on directory during moving between different parents (master) added clearing suig/sgid during write (master+mount) increased max symlink path size to 4096(posix compliance) MooseFS 3.0.93-1 (2017-06-01) (master) redesigned xattr storage (much faster and uses less memory) (master) improved hash map in xattr and acl (static -> dynamic) (cgi+cli) added possibility to define master group as set of IP adresses divided by comma or semicolon (cs) fixed using fsync on closed descriptors (after change FSYNC_BEFORE_CLOSE option) (master) fixed removing default acl (master+mount) added support for basic Windows attributes (hidden, ro, system, archive) (cgi+cli) fixed working with followers only (all) added api for reading config parameters from master and chunkserver (tools) increased timeout from 10 seconds to 20 seconds (needed for huge snapshots) MooseFS 3.0.92-1 (2017-04-27) (master+tools) added chunk slices to mfsappendchunks (tools) added archive mode tools (master+mount) fixed getfacl (unnecessary check for read rights for uid/gid) (master) fixed changing acl mask during setattr Best regards, Peter / MooseFS Team -- Piotr Robert Konopelko | mobile: +48 601 476 440 MooseFS Client Support Team | moosefs.com <https://moosefs.com/> > On 10 Apr 2017, at 6:04 PM, Piotr Robert Konopelko <pio...@mo...> wrote: > > Dear MooseFS Users, > > We are proud to annonce, that MooseFS 3.0.91 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.88> as stable! > This version includes bugfixes and improves stability. > > If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! > > > Please find the changes in MooseFS 3 since 3.0.88 below: > MooseFS 3.0.91-1 (2017-04-07) > (all) silence false warnings generated by static analyzers (clang and cppcheck) > (master) fixed quota testing routine used during move/rename > (all) added README.md to distribution > (cs+mount) decreased delay in conncache > (mount) fixed reading done by many (20+) threads using one descriptor (premature removing requests from queue during cleaning) > > MooseFS 3.0.90-1 (2017-03-15) > (master) fixed move/rename with quota > (master) fixed chunk counters shown in cli/cgi > (master+tools) added option preserve hardlinks to mfsmakesnapshot > (master) fixed acl copying during mfsmakesnapshot > > MooseFS 3.0.89-1 (2017-02-21) > (mount) added fixing file length in all inodes after write > (cs) split bitfiled into separate bytes (fixed potential race condition) > (master) setting operation to NONE before sending status (silence unnecessary messages in some cases) > (cs) increased verbosity of crc-error messages > (cs) fixed invalidating preserved block in case of truncate down followed by truncate up > (mount) increased master-proxy buffer sizes > > > > Best regards, > Peter / MooseFS Team > > -- > Piotr Robert Konopelko > MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> >> On 9 Feb 2017, at 3:12 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >> >> Dear MooseFS Users, >> >> We are proud to annonce, that MooseFS 3.0.88 has been released <https://github.com/moosefs/moosefs/releases/tag/v3.0.88> as stable today! >> This version includes bugfixes and improves stability (mainly concerning MooseFS Client). >> >> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Opening an issue on GitHub <https://github.com/moosefs/moosefs/issues> is also appreciated. Thanks! >> >> >> Please find the changes in MooseFS 3 since 3.0.86 below: >> MooseFS 3.0.88-1 (2017-02-08) >> (mount) added read cache clean on write (same file access using different descriptors) >> (mount) added missing cond_destroy in readdata.c (fix sent by Jakub Ratajczak) >> (master) fixed initializing packet size for reading 'sustained' directory >> (all) fixed zassert for printing correct statuses in case of pthread functions >> >> MooseFS 3.0.87-1 (2017-02-01) >> (mount) fix fleng in finfo after truncate (patched by Davies Liu) >> (mount) fix overlapped read (patched by Davies Liu) >> (mount) fixed invalidating chunk cache after truncate >> (mount) fixed fleng handling in read worker >> (mount) fixed handling BREAK state in read worker >> (mount) changed handling data invalidation in read module (sometimes could be less efficient, but it is much more safer) >> (tools) fixed number parsing (patched by Pawel Gawronski) >> (cli) fixed printed host/port options >> (mount) moved pipes from requests to workers (read and write - huge decrease of descriptors used by mount) >> (mount) changed signal to broadcast in rwlock (fixed very rare read/write deadlock) >> (mount) fixed 'open descriptors' leak (lookup(with data for open)->open(with cached data)->close) >> (mount) fixed potential 'race condition' - free csdata during access >> (master) split (only internally) sustained folder into 256 subfolders (too many sustained files caused socket timeouts in master) >> >> >> Best regards, >> Peter / MooseFS Team >> >> -- >> Piotr Robert Konopelko >> MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> >>> On 02 Dec 2016, at 7:54 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>> >>> Dear MooseFS Users, >>> >>> we released the newest version MooseFS 3.0 recently: MooseFS 3.0.86. >>> This version mainly contains bugfixes and improves stability. >>> >>> >>> We strongly recommend to upgrade to the latest version, but please remember, that If you had version lower than 3.0.83 and then you upgraded your Chunkservers to v. 3.0.83 or higher, please DO NOT downgrade them! >>> In MooseFS Chunkserver v. 3.0.83 we changed Chunk header from 5k to 8k (see changelog) - this is one of major changes and it means, that Chunkserver older than 3.0.83 cannot "understand" new Chunk header, which may lead to potential data loss! >>> >>> >>> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Thanks! >>> >>> >>> Please find the changes in MooseFS 3 since 3.0.77 below: >>> MooseFS 3.0.86-1 (2016-11-30) >>> (master) fixed leader-follower resynchronization after reconnection (pro only) >>> (master) fixed rehashing condition in edge/node/chunk hashmaps (change inspired by yinjiawind) >>> >>> MooseFS 3.0.85-1 (2016-11-17) >>> (mount) fixed memory leak (also efficiency) on Linux and potential segfaults on FreeBSD (negative condition) >>> (mount) fixed race condition for inode value in write module >>> (mount) better descriptors handling (lists of free elements) >>> (mount) better releasing descriptors on FreeBSD >>> (cs) fixed time condition (patch send by yinjiawind) >>> >>> MooseFS 3.0.84-1 (2016-10-06) >>> (master) fixed setting acl-default without named users or named groups >>> (master) fixed master-follower synchronization after setting storage class >>> >>> MooseFS 3.0.83-1 (2016-09-30) >>> (cs) changed header size from 5k to 8k (due to 4k-sector hard disks) >>> >>> MooseFS 3.0.82-1 (2016-09-28) >>> (all) silenced message about using deprecated parameter 'oom_adj' >>> (mount) fixed FreeBSD delayed release mechanism >>> (mount) added rwlock for chunks >>> >>> MooseFS 3.0.81-1 (2016-07-25) >>> (mount) fixed oom killer disabling (setting oom_adj and oom_score_adj) >>> (cli) fixed displaying inactive mounts >>> (mount) added fsync before removing any locks >>> (daemons) added disabling oom killer (Linux only) >>> (all) small fixes in manpages >>> (mount) fixed handling nonblocking lock commands (unlock and try) in both locking mechanisms >>> (daemons+mount) changed default settings for limiting malloc arenas (Linux only) >>> >>> MooseFS 3.0.80-1 (2016-07-13) >>> (master) fixed chunk loop (in some cases chunks from the last hash position might be left unchecked) >>> (master) fixed storage class management (fixed has_***_labels fields) >>> >>> MooseFS 3.0.79-1 (2016-07-05) >>> (master) fixed 'flock' (change type of lock SH->EX and EX->SH caused access to freed memory and usually SEGV) >>> >>> MooseFS 3.0.78-1 (2016-06-14) >>> (cs) fixed serious error that may cause data corruption during internal rebalance (intr. in 3.0.75) >>> >>> >>> >>> Best regards, >>> Peter >>> >>> -- >>> >>> <https://moosefs.com/>Piotr Robert Konopelko >>> MooseFS Technical Support Engineer >>> e-mail: pio...@mo... <mailto:pio...@mo...> >>> www: https://moosefs.com <https://moosefs.com/> >>> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> >>> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. >>> >>> >>>> On 08 Jun 2016, at 1:04 AM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>> >>>> Dear MooseFS Users, >>>> >>>> we released the newest versions of both MooseFS 3.0 and MooseFS 2.0 recently: 3.0.77 and 2.0.89. >>>> >>>> They improve MooseFS stability and (in MooseFS 3.0) also add new features, like: >>>> Storage Classes <https://moosefs.com/documentation/moosefs-3-0.html> >>>> Possibility to mount MooseFS on Linux by issuing: mount -t moosefs mfsmaster.example.lan: /mnt/mfs >>>> File sparsification >>>> Automatic temporary maintenance mode >>>> New I/O synchronisation between different mounts >>>> If you like MooseFS, please support it by starring it on GitHub <https://github.com/moosefs/moosefs>. Thanks! >>>> >>>> >>>> Please find the changes in MooseFS 3 since 3.0.73 below: >>>> MooseFS 3.0.77-1 (2016-06-07) >>>> (mount) added assertions after packet allocation in master communication module >>>> (manpages) fixes related to storage classes >>>> (all) improved error messages used for storage classes >>>> >>>> MooseFS 3.0.76-1 (2016-06-03) >>>> (master) fixed resolving multi path for root inode >>>> (master) fixed licence expiration behaviour (pro only) >>>> >>>> MooseFS 3.0.75-1 (2016-04-20) >>>> (all) fixed cppcheck warnings/errors (mostly false negatives) >>>> (cs) added file sparsification during chunk write (also chunk replication, chunk duplication etc.) >>>> (mount) fixed write data inefficiency when I/O was performed by root >>>> (master) fixed removing too early locked chunks from data structures >>>> (tools) fixed reusing local ports (connection to master returned EADDRNOTAVAIL) >>>> (all) changed default action from restart to start >>>> (all) added exiting when user defined config (option -c) cannot be loaded >>>> (cs) changed handling chunk filename (dynamic filename generation - cs should use less memory) >>>> (netdump) changed 'moose ports only' option to 'port range' >>>> (mount) limited number of files kept as open after close >>>> (cs) changed subfolder choosing algorithm >>>> (mount) changed mutex lock to rw-lock for I/O on the same descriptor >>>> (mount) added link to mfsmount from '/sbin/mount.moosefs' (Linux only) >>>> (all) introduced "storage classes" (new goal/labels management) >>>> (master+cs) introduced 'temporary maintenance mode' (automatic maintenance mode after graceful stop of cs) >>>> (master+mount) added fix for bug in FreeBSD kernel (kernel sends truncate before first close - FreeBSD only) >>>> (cs) fixed setting malloc pools on Linux >>>> >>>> MooseFS 3.0.74-1 (2016-03-08) >>>> (master) fixed rebalance replication (check for all chunk copies for destination - not only valid) >>>> (master+mount) new mechanism for atime+mtime setting during I/O >>>> (master+mount) new I/O synchronization between different mounts (with cache invalidation) >>>> (master+mount) new chunk number/version cache (with automatic invalidation from master) >>>> (master) added mapping chunkserver IP classes (allow to have separate network for I/O and separate for other activity) >>>> (master) fixed status returned by writechunk after network down/up >>>> (master) changed trashtime from seconds to hours >>>> (master) added METADATA_SAVE_FREQ option (allow to save metadata less frequently than every hour) >>>> (master) added using in emergency (endangered chunks) all available servers for replication (even overloaded and being maintained) >>>> (master) added using chunkservers in 'internal rebalance' state in case of deleting chunks >>>> (all) spell check errors fixed (patch contributed by Dmitry Smirnov) >>>> >>>> Please find the changes in MooseFS 2.0 since 2.0.88 below: >>>> MooseFS 2.0.89-1 (2016-04-27) >>>> (master+mount) added fix for bug in FreeBSD kernel (kernel sends truncate before first close - FreeBSD only) >>>> >>>> Best regards, >>>> >>>> -- >>>> >>>> <Mail Attachment.png> <https://moosefs.com/> >>>> >>>> Piotr Robert Konopelko >>>> MooseFS Technical Support Engineer >>>> e-mail : pio...@mo... <mailto:pio...@mo...> >>>> www : https://moosefs.com <https://moosefs.com/> >>>> >>>> <Mail Attachment.png> <https://twitter.com/MooseFS><Mail Attachment.png> <https://www.facebook.com/moosefs><Mail Attachment.png> <https://www.linkedin.com/company/moosefs><Mail Attachment.png> <https://github.com/moosefs> >>>> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. >>>> >>>> >>>>> On 08 Mar 2016, at 9:24 AM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>>> >>>>> Dear MooseFS Users, >>>>> >>>>> we released the newest versions of both MooseFS 3 and MooseFS 2 recently: 3.0.73 and 2.0.88. >>>>> >>>>> Please find the changes in MooseFS 3 since 3.0.71 below: >>>>> >>>>> MooseFS 3.0.73-1 (2016-02-11) >>>>> (master) fixed restoring ARCHCHG from changelog >>>>> (cli+cgi) fixed displaying master list with followers only (pro version only) >>>>> (master) added using size and length quota to fix disk usage values (statfs) >>>>> (master) fixed xattr bug which may lead to data corruption and segfaults (intr. in 2.1.1) >>>>> (master) added 'node_info' packet >>>>> (tools) added '-p' option to 'mfsdirinfo' - 'precise mode' >>>>> (master) fixed edge renumeration >>>>> (master) added detecting of wrong edge numbers and force renumeration in such case >>>>> >>>>> MooseFS 3.0.72-1 (2016-02-04) >>>>> (master+cgi+cli) added global 'umask' option to exports.cfg >>>>> (all) changed address of FSF in GPL licence text >>>>> (debian) removed obsolete conffiles >>>>> (debian) fixed copyright file >>>>> (mount) fixed parsing mfsmount.cfg (system options like nodev,noexec etc. were ommited) >>>>> (master) changed way how cs internal rebalance state is treated by master (as 'grace' state instead of 'overloaded') >>>>> (mount) fixed bug in read module (setting etab after ranges realloc) >>>>> (tools) removed obsoleted command 'mfssnapshot' >>>>> >>>>> >>>>> Please find the changes in MooseFS 2 since 2.0.83 below: >>>>> >>>>> MooseFS 2.0.88-1 (2016-03-02) >>>>> (master) added METADATA_SAVE_FREQ option (allow to save metadata less frequently than every hour) >>>>> >>>>> MooseFS 2.0.87-1 (2016-02-23) >>>>> (master) fixed status returned by writechunk after network down/up >>>>> >>>>> MooseFS 2.0.86-1 (2016-02-22) >>>>> (master) fixed initialization of ATIME_MODE >>>>> >>>>> MooseFS 2.0.85-1 (2016-02-11) >>>>> (master) added ATIME_MODE option to set atime modification behaviour >>>>> (master) added using size and length quota to fix disk usage values (statfs) >>>>> (all) changed address of FSF in GPL licence text >>>>> (debian) removed obsolete conffiles >>>>> (debian) fixed copyright file >>>>> (mount) fixed parsing mfsmount.cfg (system options like nodev,noexec etc. were ommited) >>>>> (tools) removed obsoleted command 'mfssnapshot' >>>>> >>>>> MooseFS 2.0.84-1 (2016-01-19) >>>>> (mount) fixed setting file length in write module during truncate (fixes "git svn" case) >>>>> >>>>> Best regards, >>>>> >>>>> -- >>>>> >>>>> <Mail Attachment.png> <https://moosefs.com/> >>>>> >>>>> Piotr Robert Konopelko >>>>> MooseFS Technical Support Engineer >>>>> e-mail : pio...@mo... <mailto:pio...@mo...> >>>>> www : https://moosefs.com <https://moosefs.com/> >>>>> >>>>> <Mail Attachment.png> <https://twitter.com/MooseFS><Mail Attachment.png> <https://www.facebook.com/moosefs><Mail Attachment.png> <https://www.linkedin.com/company/moosefs><Mail Attachment.png> <https://github.com/moosefs> >>>>> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. >>>>> >>>>> >>>>>> On 27 Jan 2016, at 5:51 PM, Piotr Robert Konopelko <pio...@mo... <mailto:pio...@mo...>> wrote: >>>>>> >>>>>> Dear MooseFS Users, >>>>>> >>>>>> today we published the newest version from 3.x branch: 3.0.71. >>>>>> >>>>>> Please find the changes since 3.0.69 below: >>>>>> >>>>>> MooseFS 3.0.71-1 (2016-01-21) >>>>>> (master) fixed emptying trash issue (intr. in 3.0.64) >>>>>> (master) fixed possible segfault in chunkservers database (intr. in 3.0.67) >>>>>> (master) changed trash part choice from nondeterministic to deterministic >>>>>> >>>>>> MooseFS 3.0.70-1 (2016-01-19) >>>>>> (cgi+cli) fixed displaying info when there are no active masters (intr. in 3.0.67) >>>>>> (mount+common) refactoring code to be Windows ready >>>>>> (mount) added option 'mfsflattrash' (makes trash look like before version 3.0.64) >>>>>> (mount) added fixes for NetBSD (patch contributed by Tom Ivar Helbekkmo) >>>>>> >>>>>> Best regards, >>>>>> >>>>>> -- >>>>>> Piotr Robert Konopelko >>>>>> MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> >>>>> >>>>> >>>> >>>> >>> >> > > ------------------------------------------------------------------------------ > 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: WK <wk...@bn...> - 2017-06-29 17:18:18
|
I see some Pi code on the website. https://moosefs.com/download/rpi2.html I have a project, where I need to create an SSH gateway where the homedirs are moose mounted (for periodic sftp backups) Normally we would just use a cast off desktop for this sort of thing, but I'm intrigued by using a Rpi. Any one here using Pi's on MFS? Is the code stable and maintained? Are there resource limits? -wk |
84 messages has been excluded from this view by a project administrator.
