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: Piotr R. K. <pio...@mo...> - 2016-06-09 11:19:33
|
Dear MooseFS Users, after some notifications from Users about incompatibility of 3.0.x Mounts with 2.0.x Master Servers, we decided to rollback default "stable" symlink in our repository structure to 2.0.89. It doesn't mean, that MooseFS 3.0.77 is not stable! We did it only to prevent compatibility issues of 3.0.x Mounts with 2.0.x Masters in Users' MooseFS instances. We still recommend and encourage you to upgrade to 3.0.77. It can be done by typing explicite "3.0.75" instead of "stable" in repo URL (as I mentioned in my previous mail in reply to Steven's mail - attaching in quote). Tomorrow we are going to propose a better repository URLs structure. Please watch the mailing list and our website <https://moosefs.com/download.html> tomorrow. 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 6:14 PM, Piotr Robert Konopelko <pio...@mo...> wrote: > > Dear Steven, > > thank you very much for your remark. I'd like to let you (and the rest of MooseFS-Users) know, that it is possible to "control" the version of MooseFS on moosefs.list repo sources file. It's described on MooseFS Download page <https://moosefs.com/download.html>. Let me quote some essentials: > > There is also a possibility to use version number instead of "branch" if you want to decide exactly which version of MooseFS you want to upgrade to (e.g. 3.0.75-1): > > http://ppa.moosefs.com/3.0.75/[rest <http://ppa.moosefs.com/3.0.75/[rest> of url] > If you want to use this option, please remember you need to manually change version number on each server to newer one before doing an upgrade. > > > So it is possible to set up your MooseFS repository in a "controlled way". In such case, just put in /etc/apt/sources.list.d/moosefs.list (or equivalent in other OS) the following entry: > > deb http://ppa.moosefs.com/ <http://ppa.moosefs.com/>2.0.89/apt/ubuntu/trusty trusty main > > Then, when your upgrade is planned, before starting it, just change it to: > > deb http://ppa.moosefs.com/ <http://ppa.moosefs.com/>3.0.77/apt/ubuntu/trusty trusty main > > > This is a very good way to control MooseFS upgrades, since e.g. MooseFS Master Server upgrade usually has to be planned in production environments. The only con of this way is that you have to check manually if there's a newer version of MooseFS available. > > > 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 Jun 2016, at 4:24 PM, Wilson, Steven M <st...@pu... <mailto:st...@pu...>> wrote: >> >> That's great news... thanks! >> >> One warning to other users: Now that v. 3.0.x is the stable version, any package upgrade you perform will automatically pull in this version. I was reminded of this today when I had to take down one of my MooseFS master servers to replace its UPS. Since I was rebooting the master server, I decided to perform a full package upgrade on it (Ubuntu: apt-get dist-upgrade). That, of course, upgraded all MooseFS components to 3.0.77 from 2.0.89. But I have numerous MooseFS master servers still running 2.0.89 and the new mfsmount won't mount these older (2.0.x) MooseFS file systems. I will probably mark as held the moosefs-client package on all my workstations until I have upgraded all MooseFS master servers to 3.0.x. I hope this helps prevent an unexpected surprise to some other user! >> >> Best regards, >> Steve |
|
From: Ben T. <bt...@gm...> - 2016-06-09 02:36:22
|
On Wed, Jun 8, 2016 at 10:25 PM, Elliot Finley <efi...@gm...> wrote: > mfsmakesnapshot makes a ”real” snapshot (lazy copy, like in case of > mfsappendchunks) of some object(s) or subtree (similarly to cp -r command). > It’s atomic with respect to each SOURCE argument separately. If DESTINATION > points to already existing file, error will be reported unless -o > (overwrite) option is given. Note: if SOURCE is a directory, it’s copied as > a whole; but if it’s followed by trailing slash, only directory content is > copied. > > mfsmakesnapshot does a copy-on-write copy... i.e. only the metadata is > copied. it happens very quickly. if your tens of thousands of files are > all in a single directory tree, just copy the head directory. > Thank you Elliot, I think this is exactly what I was looking for. |
|
From: Elliot F. <efi...@gm...> - 2016-06-09 02:25:27
|
mfsmakesnapshot makes a ”real” snapshot (lazy copy, like in case of mfsappendchunks) of some object(s) or subtree (similarly to cp -r command). It’s atomic with respect to each SOURCE argument separately. If DESTINATION points to already existing file, error will be reported unless -o (overwrite) option is given. Note: if SOURCE is a directory, it’s copied as a whole; but if it’s followed by trailing slash, only directory content is copied. mfsmakesnapshot does a copy-on-write copy... i.e. only the metadata is copied. it happens very quickly. if your tens of thousands of files are all in a single directory tree, just copy the head directory. On Wed, Jun 8, 2016 at 7:18 PM, Ben Timby <bt...@gm...> wrote: > Hi all, I am looking for a way to do a fast file copy with MooseFS. Today > with fuse mount MFS does copies the usual way. Open source for reading, > open destination for writing and then loop, reading and writing data > between the files. > > It seems to me that MFS could do a much faster copy operation by not > involving the client at all and simply asking the mfsmaster for a new > metadata entry and then cloning chunks. > > Am I wrong? Is there a way to do this? I ask because we are copying tens > of thousands of files and need it to happen very quickly. > > Thanks. > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users > > |
|
From: Ben T. <bt...@gm...> - 2016-06-09 01:19:00
|
Hi all, I am looking for a way to do a fast file copy with MooseFS. Today with fuse mount MFS does copies the usual way. Open source for reading, open destination for writing and then loop, reading and writing data between the files. It seems to me that MFS could do a much faster copy operation by not involving the client at all and simply asking the mfsmaster for a new metadata entry and then cloning chunks. Am I wrong? Is there a way to do this? I ask because we are copying tens of thousands of files and need it to happen very quickly. Thanks. |
|
From: Piotr R. K. <pio...@mo...> - 2016-06-08 16:15:34
|
Dear Steven, thank you very much for your remark. I'd like to let you (and the rest of MooseFS-Users) know, that it is possible to "control" the version of MooseFS on moosefs.list repo sources file. It's described on MooseFS Download page <https://moosefs.com/download.html>. Let me quote some essentials: There is also a possibility to use version number instead of "branch" if you want to decide exactly which version of MooseFS you want to upgrade to (e.g. 3.0.75-1): http://ppa.moosefs.com/3.0.75/[rest of url] If you want to use this option, please remember you need to manually change version number on each server to newer one before doing an upgrade. So it is possible to set up your MooseFS repository in a "controlled way". In such case, just put in /etc/apt/sources.list.d/moosefs.list (or equivalent in other OS) the following entry: deb http://ppa.moosefs.com/2.0.89/apt/ubuntu/trusty trusty main Then, when your upgrade is planned, before starting it, just change it to: deb http://ppa.moosefs.com/3.0.77/apt/ubuntu/trusty trusty main This is a very good way to control MooseFS upgrades, since e.g. MooseFS Master Server upgrade usually has to be planned in production environments. The only con of this way is that you have to check manually if there's a newer version of MooseFS available. Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 08 Jun 2016, at 4:24 PM, Wilson, Steven M <st...@pu...> wrote: > > That's great news... thanks! > > One warning to other users: Now that v. 3.0.x is the stable version, any package upgrade you perform will automatically pull in this version. I was reminded of this today when I had to take down one of my MooseFS master servers to replace its UPS. Since I was rebooting the master server, I decided to perform a full package upgrade on it (Ubuntu: apt-get dist-upgrade). That, of course, upgraded all MooseFS components to 3.0.77 from 2.0.89. But I have numerous MooseFS master servers still running 2.0.89 and the new mfsmount won't mount these older (2.0.x) MooseFS file systems. I will probably mark as held the moosefs-client package on all my workstations until I have upgraded all MooseFS master servers to 3.0.x. I hope this helps prevent an unexpected surprise to some other user! > > Best regards, > Steve > > From: Krzysztof Kielak <krz...@mo...> > Sent: Wednesday, June 8, 2016 6:02 AM > To: moosefs-users > Subject: [MooseFS-Users] MooseFS 3.0.77 - Stable Release > > Dear MooseFS Users, > > We are excited to announce that today, after extensive internal testing, we have released the stable version of MooseFS 3.0.77 (Pro and Community). > > With MooseFS 3.0.77 release we introduce great new features: > - Storage Classes for better data distribution and redundancy management, > - Global locks support compatible with POSIX ioctl() and lockf() semantics and BSD compatible flock() semantics, > - New I/O synchronisation mechanism between different mounts, for better handling concurrent I/O operations from different clients, > - ATMM (Automatic Temporary Maintenance Mode), > - Automatic File "sparsification". > > We have already started working on version 4.0.x, that soon should be available in our current repository (development version). MooseFS 4.0.x, among other features, will allow to store data in Distributed RAID organisation. > > Best Regards, > Krzysztof Kielak > Moosefs.com <http://moosefs.com/> | Director of Operations and Customer Support > Mobile: +48 601 476 440 > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Wilson, S. M <st...@pu...> - 2016-06-08 14:24:27
|
That's great news... thanks! One warning to other users: Now that v. 3.0.x is the stable version, any package upgrade you perform will automatically pull in this version. I was reminded of this today when I had to take down one of my MooseFS master servers to replace its UPS. Since I was rebooting the master server, I decided to perform a full package upgrade on it (Ubuntu: apt-get dist-upgrade). That, of course, upgraded all MooseFS components to 3.0.77 from 2.0.89. But I have numerous MooseFS master servers still running 2.0.89 and the new mfsmount won't mount these older (2.0.x) MooseFS file systems. I will probably mark as held the moosefs-client package on all my workstations until I have upgraded all MooseFS master servers to 3.0.x. I hope this helps prevent an unexpected surprise to some other user! Best regards, Steve ________________________________ From: Krzysztof Kielak <krz...@mo...> Sent: Wednesday, June 8, 2016 6:02 AM To: moosefs-users Subject: [MooseFS-Users] MooseFS 3.0.77 - Stable Release Dear MooseFS Users, We are excited to announce that today, after extensive internal testing, we have released the stable version of MooseFS 3.0.77 (Pro and Community). With MooseFS 3.0.77 release we introduce great new features: - Storage Classes for better data distribution and redundancy management, - Global locks support compatible with POSIX ioctl() and lockf() semantics and BSD compatible flock() semantics, - New I/O synchronisation mechanism between different mounts, for better handling concurrent I/O operations from different clients, - ATMM (Automatic Temporary Maintenance Mode), - Automatic File "sparsification". We have already started working on version 4.0.x, that soon should be available in our current repository (development version). MooseFS 4.0.x, among other features, will allow to store data in Distributed RAID organisation. Best Regards, Krzysztof Kielak Moosefs.com<http://moosefs.com> | Director of Operations and Customer Support Mobile: +48 601 476 440 |
|
From: Krzysztof K. <krz...@mo...> - 2016-06-08 10:02:38
|
Dear MooseFS Users, We are excited to announce that today, after extensive internal testing, we have released the stable version of MooseFS 3.0.77 (Pro and Community). With MooseFS 3.0.77 release we introduce great new features: - Storage Classes for better data distribution and redundancy management, - Global locks support compatible with POSIX ioctl() and lockf() semantics and BSD compatible flock() semantics, - New I/O synchronisation mechanism between different mounts, for better handling concurrent I/O operations from different clients, - ATMM (Automatic Temporary Maintenance Mode), - Automatic File "sparsification". We have already started working on version 4.0.x, that soon should be available in our current repository (development version). MooseFS 4.0.x, among other features, will allow to store data in Distributed RAID organisation. Best Regards, Krzysztof Kielak Moosefs.com | Director of Operations and Customer Support Mobile: +48 601 476 440 |
|
From: Piotr R. K. <pio...@mo...> - 2016-06-07 23:21:00
|
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, -- <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 Mar 2016, at 9:24 AM, Piotr Robert Konopelko <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/>------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_________________________________________ <http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_________________________________________> >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://makebettercode.com/inteldaal-eval_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Wilson, S. M <st...@pu...> - 2016-06-02 12:30:55
|
?Hi Aleksander, Okay, thanks! I'll look forward to upgrading to MooseFS 3.0 in the near future. Regards, Steve ________________________________ From: Aleksander Wieliczko <ale...@mo...> Sent: Thursday, June 2, 2016 6:04 AM To: Wilson, Steven M; moo...@li... Subject: Re: [MooseFS-Users] MooseFS and default ACLs Hi Steve, Thank you for this information. You are right. There is a problem with setting up default permissions. We would like to inform that problem appear only in MooseFS 2.0. MooseFS 3.0 has no problems with ACL. Please consider update to version 3.0. Next week we will announce that version 3.0 is stable. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com<moosefs.com> |
|
From: Aleksander W. <ale...@mo...> - 2016-06-02 10:04:45
|
Hi Steve, Thank you for this information. You are right. There is a problem with setting up default permissions. We would like to inform that problem appear only in MooseFS 2.0. MooseFS 3.0 has no problems with ACL. Please consider update to version 3.0. Next week we will announce that version 3.0 is stable. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> |
|
From: Wilson, S. M <st...@pu...> - 2016-06-01 20:53:55
|
Hi, It looks like there are some problems with default ACL support in MooseFS. I tried executing the following command on a directory named "a": ?setfacl -m d:g::---,d:o::--- a and it appears that nothing is changed (output from getfacl): # file: a # owner: root # group: root user::rwx group::r-x other::r-x On an XFS file system I'll see the following from getfacl: # file: a # owner: root # group: root user::rwx group::r-x other::r-x default:user::rwx default:group::--- default:other::--- ?The mfsmaster is v.2.0.77 and the client (mfsmount) is also v.2.0.77. ?Thanks! Steve |
|
From: Michael T. <mic...@ho...> - 2016-05-05 02:51:24
|
Hi Aleksander,
Thank you for the reply. Is the threshold on IO operations a fixed number? I'm hoping that, in the scenario I described, I'll hit the USB 3.0 bandwidth limit before I hit the "prefer local" threshold.
--- mike t.
Subject: Re: [MooseFS-Users] Chunkserver is also a client
To: mic...@ho...; moo...@li...
From: ale...@mo...
Date: Wed, 4 May 2016 10:20:11 +0200
Hi,
All depends.
MooseFS has "prefer local" chunks mechanism but only under certain
conditions.
If number of IO operations on your local chunkserver is low, you
will get chunks only from local machine.
In case of higher number IO operations on your local chunkserver,
chunks will be copied from other chunkservers.
Best regards
Aleksander Wieliczko
Technical Support Engineer
MooseFS.com
On 05/04/2016 04:49 AM, Michael Tinsay wrote:
Hi.
I've been meaning to ask this for some time now.
My current setup now is MooseFS 2.x with 1 Master, 1
Metalogger, 3 Chunkservers, and all files have copies=3 so
that all chunkservers will each have a complete set of chunks.
There are >5 clients connecting to this setup.
Now, suppose that in one of the chunkservers, I mount mfs'
root directory and start copying files to an external USB hard
drive.
My question is: will the chunkserver retrieve chunks from
the other chunkservers for the files I'm copying? Or does the
mfs client code contain logic to determine that the chunks
needed are available locally and, thus, all chunks are read
locally which would in theory make the copying process go as
fast as it could.
--- mike t.
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_________________________________________
moosefs-users mailing list
moo...@li...
https://lists.sourceforge.net/lists/listinfo/moosefs-users
|
|
From: Aleksander W. <ale...@mo...> - 2016-05-04 08:20:24
|
Hi, All depends. MooseFS has "prefer local" chunks mechanism but only under certain conditions. If number of IO operations on your local chunkserver is low, you will get chunks only from local machine. In case of higher number IO operations on your local chunkserver, chunks will be copied from other chunkservers. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 05/04/2016 04:49 AM, Michael Tinsay wrote: > Hi. > > I've been meaning to ask this for some time now. > > My current setup now is MooseFS 2.x with 1 Master, 1 Metalogger, 3 > Chunkservers, and all files have copies=3 so that all chunkservers > will each have a complete set of chunks. There are >5 clients > connecting to this setup. > > Now, suppose that in one of the chunkservers, I mount mfs' root > directory and start copying files to an external USB hard drive. > > My question is: will the chunkserver retrieve chunks from the other > chunkservers for the files I'm copying? Or does the mfs client code > contain logic to determine that the chunks needed are available > locally and, thus, all chunks are read locally which would in theory > make the copying process go as fast as it could. > > > --- mike t. > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > > > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Valeri G. <ga...@ki...> - 2016-05-04 03:19:42
|
On Tue, May 3, 2016 9:49 pm, Michael Tinsay wrote: > Hi. > I've been meaning to ask this for some time now. > My current setup now is MooseFS 2.x with 1 Master, 1 Metalogger, 3 > Chunkservers, and all files have copies=3 so that all chunkservers will > each have a complete set of chunks. There are >5 clients connecting to > this setup. > Now, suppose that in one of the chunkservers, I mount mfs' root directory > and start copying files to an external USB hard drive. > My question is: will the chunkserver retrieve chunks from the other > chunkservers for the files I'm copying? Or does the mfs client code > contain logic to determine that the chunks needed are available locally > and, thus, all chunks are read locally which would in theory make the > copying process go as fast as it could. Not an answer, just a thought. You can measure it. Take really good USB-3 drive, or just copy to some fast internal filesystem, time what it takes. Then repeat the same after throttling network interface down (simple thing is just to put 10 mbps switch or hub between your 1 gbps ethernet port of your server and 1 gbps port of switch it normally is connected to). But I would like to hear the answer too, thanks for great question! Valeri > > --- mike t. > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ |
|
From: Michael T. <mic...@ho...> - 2016-05-04 02:49:27
|
Hi. I've been meaning to ask this for some time now. My current setup now is MooseFS 2.x with 1 Master, 1 Metalogger, 3 Chunkservers, and all files have copies=3 so that all chunkservers will each have a complete set of chunks. There are >5 clients connecting to this setup. Now, suppose that in one of the chunkservers, I mount mfs' root directory and start copying files to an external USB hard drive. My question is: will the chunkserver retrieve chunks from the other chunkservers for the files I'm copying? Or does the mfs client code contain logic to determine that the chunks needed are available locally and, thus, all chunks are read locally which would in theory make the copying process go as fast as it could. --- mike t. |
|
From: Valeri G. <ga...@ki...> - 2016-05-02 13:53:54
|
Hi Piotr, Thank you! And please, thank everybody else on my behalf! Valeri On Mon, May 2, 2016 8:26 am, Piotr Robert Konopelko wrote: > Hi Valeri, > > the ports have been accepted and included into ports mainstream: > > * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209109 > * https://svnweb.freebsd.org/ports?view=revision&revision=414381 > > so you can compile and install MooseFS 2.0.89 from ports if you want. > > > The FreeBSD packages are still in 2.0.88, so you have to wait for them a > bit: > http://portsmon.freebsd.org/portoverview.py?category=sysutils&portname=moosefs&wildcard=yes > > (of course you can get our packages, as I described in my previous mail). > > Please let us know, if the update resolved your issue. > > > Best regards, > > -- > Piotr Robert Konopelko > MooseFS Technical Support Engineer | moosefs.com > >> On 27 Apr 2016, at 10:37 PM, Valeri Galtsev <ga...@ki...> >> wrote: >> >> Thank you, gentlemen! >> >> Valeri >> >> On Wed, April 27, 2016 1:44 pm, Piotr Robert Konopelko wrote: >>> Dear Valeri, >>> >>> I'd like to let you know, that we've just released MooseFS 2.0.89 with >>> fix. >>> >>> Corresponding commit: >>> https://github.com/moosefs/moosefs/commit/b0125cf44cb40cc48d5b730088180654a0c8329c >>> <https://github.com/moosefs/moosefs/commit/b0125cf44cb40cc48d5b730088180654a0c8329c> >>> >>> >>> You can download it as follows: >>> >>> Packages for FreeBSD - from our website: >>> https://moosefs.com/download/freebsd.html >>> <https://moosefs.com/download/freebsd.html> >>> Sources - from our website: https://moosefs.com/download/sources.html >>> <https://moosefs.com/download/sources.html> >>> Sources - from GitHub: https://github.com/moosefs/moosefs/tree/2.0.x >>> <https://github.com/moosefs/moosefs/tree/2.0.x> >>> >>> >>> I'm going to update official ports in FreeBSD ports collection today, >>> so >>> they should be available in a few days. >>> >>> Best regards, >>> >>> -- >>> >>> <https://moosefs.com/> >>> Piotr Robert Konopelko >>> MooseFS Technical Support Engineer >>> e-mail : pio...@mo... >>> <mailto:pio...@mo...> >>> www : https://moosefs.com <https://moosefs.com/> >>> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> >>> <https://www.linkedin.com/company/moosefs> >>> <https://github.com/moosefs> >>> >>> This email and any files transmitted with it are confidential and >>> intended >>> solely for the use of the individual or entity to whom they are >>> addressed. >>> If you have received it by mistake, please let us know by e-mail reply >>> and >>> delete it from your system; you may not copy this message or disclose >>> its >>> contents to anyone. Finally, the recipient should check this email and >>> any >>> attachments for the presence of viruses. Core Technology accepts no >>> liability for any damage caused by any virus transmitted by this email. >>> >>> >>>> On 27 Apr 2016, at 2:58 PM, Aleksander Wieliczko >>>> <ale...@mo...> wrote: >>>> >>>> Hi Valeri, >>>> >>>> I would like to tell you that this strange behaviour is connected with >>>> FreeBSD kernel not with MooseFS. >>>> >>>> Mainly FreeBSD kernel sending setattr command before first close. >>>> Today we will publish MooseFS 2.0.89 packages with fix for FreeBSD >>>> kernel. >>>> >>>> After upgrade please let us know if all is working correctly. >>>> >>>> Best regards >>>> Aleksander Wieliczko >>>> Technical Support Engineer >>>> MooseFS.com <x-msg://14/moosefs.com> >>>> >>>> >>>> >>>> On 04/25/2016 02:07 PM, Aleksander Wieliczko wrote: >>>>> Hi Valeri, >>>>> >>>>> Excuse me. >>>>> I missed you previous mail. >>>>> >>>>> Right now I will test this issue on FreeBSD 9.3 >>>>> >>>>> Best regards >>>>> Aleksander Wieliczko >>>>> Technical Support Engineer >>>>> MooseFS.com <x-msg://14/moosefs.com> >>>>> >>>>> On 04/25/2016 01:46 PM, Aleksander Wieliczko wrote: >>>>>> Hi Valeri, >>>>>> >>>>>> I would like to inform you that we have made simple test in our >>>>>> development environment, and we do not observe such a behaviour. >>>>>> This is what we have: >>>>>> >>>>>> FreeBSD 10.2 >>>>>> MFS version 2.0.88-1 >>>>>> FUSE library version: 2.9.5 >>>>>> >>>>>> root@freebsd:~ # stat /mnt/mfs/test/* >>>>>> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:19:41 2016" >>>>>> "Apr >>>>>> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test1 >>>>>> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:23:26 2016" >>>>>> "Apr >>>>>> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test2 >>>>>> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:23:50 2016" >>>>>> "Apr >>>>>> 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test3 >>>>>> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:23:58 2016" >>>>>> "Apr >>>>>> 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test4 >>>>>> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:24:07 2016" >>>>>> "Apr >>>>>> 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test5 >>>>>> >>>>>> root@freebsd:~ # rsync -avu /mnt/mfs/test /tmp/ >>>>>> >>>>>> root@freebsd:~ # stat /mnt/mfs/test/* >>>>>> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:31:36 2016" >>>>>> "Apr >>>>>> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test1 >>>>>> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:31:36 2016" >>>>>> "Apr >>>>>> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test2 >>>>>> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:31:36 2016" >>>>>> "Apr >>>>>> 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test3 >>>>>> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:31:36 2016" >>>>>> "Apr >>>>>> 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test4 >>>>>> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:31:36 2016" >>>>>> "Apr >>>>>> 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 >>>>>> 1 >>>>>> 0 /mnt/mfs/test/test5 >>>>>> >>>>>> You see, that only atime has been changed. >>>>>> >>>>>> Question is which FreeBSD version you have? >>>>>> >>>>>> I'm looking forward to hearing from you. >>>>>> Aleksander Wieliczko >>>>>> Technical Support Engineer >>>>>> MooseFS.com <x-msg://14/moosefs.com> >>>>>> >>>>>> >>>>>> On 04/22/2016 07:03 AM, Jakub Kruszona-Zawadzki wrote: >>>>>>> On 21 Apr, 2016, at 16:33, Valeri Galtsev >>>>>>> <ga...@ki...> >>>>>>> <mailto:ga...@ki...> wrote: >>>>>>> >>>>>>>> Dear Experts, >>>>>>>> >>>>>>>> I have sort of weirdness I just stumbled over. >>>>>>>> >>>>>>>> I migrates some directories to moosefs (free opes source version, >>>>>>>> standard >>>>>>>> installation "by the book" on FreeBSD). At some point I decided to >>>>>>>> migrate >>>>>>>> the directory back to local (UFS) filesystem on the machine. Here >>>>>>>> is >>>>>>>> weirdness I observe: >>>>>>>> >>>>>>>> after i run >>>>>>>> >>>>>>>> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs >>>>>>>> >>>>>>>> I do get the content of directory on local filesystem as expected >>>>>>>> with all >>>>>>>> correct file attributes (user/group ownership, creation time, >>>>>>>> content). >>>>>>>> However, the source files on moosefs change their time stamps, as >>>>>>>> if >>>>>>>> the >>>>>>>> report last access time instead of creation time. They were >>>>>>>> reporting >>>>>>>> correct creation times after they were rsync'ed from local >>>>>>>> filesystem to >>>>>>>> moosefs originally. This basically renders rsync command useless >>>>>>>> (and >>>>>>>> damaging if you care about file creation times) when you rsync >>>>>>>> from >>>>>>>> moosefs (elsewhere). >>>>>>>> >>>>>>>> What am I doing wrong? I've used Linux and Unix for over decade an >>>>>>>> a >>>>>>>> half, >>>>>>>> ans used rsync over comparable period of time. What I hit with >>>>>>>> moosefs >>>>>>>> gives me kind of shock, and I can't figure myself what could I be >>>>>>>> doing >>>>>>>> wrong. >>>>>>>> >>>>>>>> Thanks in advance for all your advices. >>>>>>>> >>>>>>>> Valeri >>>>>>> We have changed atime/mtime management in MooseFS recently (in >>>>>>> version 3.0.74), so the question is which version of MooseFS do you >>>>>>> use? >>>>>>> >>>>>>> It looks like a bug in MooseFS, so we need the version, because we >>>>>>> have two options here. >>>>>>> The bug was in previous atime/mtime mechanism (pre 3.0.74) or there >>>>>>> is a bug in current mechanism. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Find and fix application performance issues faster with Applications >>>>>> Manager >>>>>> Applications Manager provides deep performance insights into >>>>>> multiple >>>>>> tiers of >>>>>> your business applications. It resolves application problems quickly >>>>>> and >>>>>> reduces your MTTR. Get your free trial! >>>>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >>>>>> <https://ad.doubleclick.net/ddm/clk/302982198;130105516;z> >>>>>> >>>>>> _________________________________________ >>>>>> 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> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Find and fix application performance issues faster with Applications >>>>> Manager >>>>> Applications Manager provides deep performance insights into multiple >>>>> tiers of >>>>> your business applications. It resolves application problems quickly >>>>> and >>>>> reduces your MTTR. Get your free trial! >>>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >>>>> <https://ad.doubleclick.net/ddm/clk/302982198;130105516;z> >>>>> >>>>> _________________________________________ >>>>> 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> >>>> >>>> ------------------------------------------------------------------------------ >>>> Find and fix application performance issues faster with Applications >>>> Manager >>>> Applications Manager provides deep performance insights into multiple >>>> tiers of >>>> your business applications. It resolves application problems quickly >>>> and >>>> reduces your MTTR. Get your free trial! >>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_________________________________________ >>>> moosefs-users mailing list >>>> moo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/moosefs-users >>> >>> >> >> >> ++++++++++++++++++++++++++++++++++++++++ >> Valeri Galtsev >> Sr System Administrator >> Department of Astronomy and Astrophysics >> Kavli Institute for Cosmological Physics >> University of Chicago >> Phone: 773-702-4247 >> ++++++++++++++++++++++++++++++++++++++++ > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ |
|
From: Piotr R. K. <pio...@mo...> - 2016-05-02 13:26:44
|
Hi Valeri, the ports have been accepted and included into ports mainstream: * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209109 * https://svnweb.freebsd.org/ports?view=revision&revision=414381 so you can compile and install MooseFS 2.0.89 from ports if you want. The FreeBSD packages are still in 2.0.88, so you have to wait for them a bit: http://portsmon.freebsd.org/portoverview.py?category=sysutils&portname=moosefs&wildcard=yes (of course you can get our packages, as I described in my previous mail). Please let us know, if the update resolved your issue. Best regards, -- Piotr Robert Konopelko MooseFS Technical Support Engineer | moosefs.com > On 27 Apr 2016, at 10:37 PM, Valeri Galtsev <ga...@ki...> wrote: > > Thank you, gentlemen! > > Valeri > > On Wed, April 27, 2016 1:44 pm, Piotr Robert Konopelko wrote: >> Dear Valeri, >> >> I'd like to let you know, that we've just released MooseFS 2.0.89 with >> fix. >> >> Corresponding commit: >> https://github.com/moosefs/moosefs/commit/b0125cf44cb40cc48d5b730088180654a0c8329c >> <https://github.com/moosefs/moosefs/commit/b0125cf44cb40cc48d5b730088180654a0c8329c> >> >> >> You can download it as follows: >> >> Packages for FreeBSD - from our website: >> https://moosefs.com/download/freebsd.html >> <https://moosefs.com/download/freebsd.html> >> Sources - from our website: https://moosefs.com/download/sources.html >> <https://moosefs.com/download/sources.html> >> Sources - from GitHub: https://github.com/moosefs/moosefs/tree/2.0.x >> <https://github.com/moosefs/moosefs/tree/2.0.x> >> >> >> I'm going to update official ports in FreeBSD ports collection today, so >> they should be available in a few days. >> >> Best regards, >> >> -- >> >> <https://moosefs.com/> >> Piotr Robert Konopelko >> MooseFS Technical Support Engineer >> e-mail : pio...@mo... <mailto:pio...@mo...> >> www : https://moosefs.com <https://moosefs.com/> >> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> >> <https://www.linkedin.com/company/moosefs> >> <https://github.com/moosefs> >> >> This email and any files transmitted with it are confidential and intended >> solely for the use of the individual or entity to whom they are addressed. >> If you have received it by mistake, please let us know by e-mail reply and >> delete it from your system; you may not copy this message or disclose its >> contents to anyone. Finally, the recipient should check this email and any >> attachments for the presence of viruses. Core Technology accepts no >> liability for any damage caused by any virus transmitted by this email. >> >> >>> On 27 Apr 2016, at 2:58 PM, Aleksander Wieliczko >>> <ale...@mo...> wrote: >>> >>> Hi Valeri, >>> >>> I would like to tell you that this strange behaviour is connected with >>> FreeBSD kernel not with MooseFS. >>> >>> Mainly FreeBSD kernel sending setattr command before first close. >>> Today we will publish MooseFS 2.0.89 packages with fix for FreeBSD >>> kernel. >>> >>> After upgrade please let us know if all is working correctly. >>> >>> Best regards >>> Aleksander Wieliczko >>> Technical Support Engineer >>> MooseFS.com <x-msg://14/moosefs.com> >>> >>> >>> >>> On 04/25/2016 02:07 PM, Aleksander Wieliczko wrote: >>>> Hi Valeri, >>>> >>>> Excuse me. >>>> I missed you previous mail. >>>> >>>> Right now I will test this issue on FreeBSD 9.3 >>>> >>>> Best regards >>>> Aleksander Wieliczko >>>> Technical Support Engineer >>>> MooseFS.com <x-msg://14/moosefs.com> >>>> >>>> On 04/25/2016 01:46 PM, Aleksander Wieliczko wrote: >>>>> Hi Valeri, >>>>> >>>>> I would like to inform you that we have made simple test in our >>>>> development environment, and we do not observe such a behaviour. >>>>> This is what we have: >>>>> >>>>> FreeBSD 10.2 >>>>> MFS version 2.0.88-1 >>>>> FUSE library version: 2.9.5 >>>>> >>>>> root@freebsd:~ # stat /mnt/mfs/test/* >>>>> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:19:41 2016" "Apr >>>>> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test1 >>>>> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:23:26 2016" "Apr >>>>> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test2 >>>>> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:23:50 2016" "Apr >>>>> 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test3 >>>>> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:23:58 2016" "Apr >>>>> 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test4 >>>>> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:24:07 2016" "Apr >>>>> 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test5 >>>>> >>>>> root@freebsd:~ # rsync -avu /mnt/mfs/test /tmp/ >>>>> >>>>> root@freebsd:~ # stat /mnt/mfs/test/* >>>>> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:31:36 2016" "Apr >>>>> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test1 >>>>> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:31:36 2016" "Apr >>>>> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test2 >>>>> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:31:36 2016" "Apr >>>>> 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test3 >>>>> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:31:36 2016" "Apr >>>>> 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test4 >>>>> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:31:36 2016" "Apr >>>>> 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 >>>>> 0 /mnt/mfs/test/test5 >>>>> >>>>> You see, that only atime has been changed. >>>>> >>>>> Question is which FreeBSD version you have? >>>>> >>>>> I'm looking forward to hearing from you. >>>>> Aleksander Wieliczko >>>>> Technical Support Engineer >>>>> MooseFS.com <x-msg://14/moosefs.com> >>>>> >>>>> >>>>> On 04/22/2016 07:03 AM, Jakub Kruszona-Zawadzki wrote: >>>>>> On 21 Apr, 2016, at 16:33, Valeri Galtsev <ga...@ki...> >>>>>> <mailto:ga...@ki...> wrote: >>>>>> >>>>>>> Dear Experts, >>>>>>> >>>>>>> I have sort of weirdness I just stumbled over. >>>>>>> >>>>>>> I migrates some directories to moosefs (free opes source version, >>>>>>> standard >>>>>>> installation "by the book" on FreeBSD). At some point I decided to >>>>>>> migrate >>>>>>> the directory back to local (UFS) filesystem on the machine. Here is >>>>>>> weirdness I observe: >>>>>>> >>>>>>> after i run >>>>>>> >>>>>>> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs >>>>>>> >>>>>>> I do get the content of directory on local filesystem as expected >>>>>>> with all >>>>>>> correct file attributes (user/group ownership, creation time, >>>>>>> content). >>>>>>> However, the source files on moosefs change their time stamps, as if >>>>>>> the >>>>>>> report last access time instead of creation time. They were >>>>>>> reporting >>>>>>> correct creation times after they were rsync'ed from local >>>>>>> filesystem to >>>>>>> moosefs originally. This basically renders rsync command useless >>>>>>> (and >>>>>>> damaging if you care about file creation times) when you rsync from >>>>>>> moosefs (elsewhere). >>>>>>> >>>>>>> What am I doing wrong? I've used Linux and Unix for over decade an a >>>>>>> half, >>>>>>> ans used rsync over comparable period of time. What I hit with >>>>>>> moosefs >>>>>>> gives me kind of shock, and I can't figure myself what could I be >>>>>>> doing >>>>>>> wrong. >>>>>>> >>>>>>> Thanks in advance for all your advices. >>>>>>> >>>>>>> Valeri >>>>>> We have changed atime/mtime management in MooseFS recently (in >>>>>> version 3.0.74), so the question is which version of MooseFS do you >>>>>> use? >>>>>> >>>>>> It looks like a bug in MooseFS, so we need the version, because we >>>>>> have two options here. >>>>>> The bug was in previous atime/mtime mechanism (pre 3.0.74) or there >>>>>> is a bug in current mechanism. >>>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Find and fix application performance issues faster with Applications >>>>> Manager >>>>> Applications Manager provides deep performance insights into multiple >>>>> tiers of >>>>> your business applications. It resolves application problems quickly >>>>> and >>>>> reduces your MTTR. Get your free trial! >>>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >>>>> <https://ad.doubleclick.net/ddm/clk/302982198;130105516;z> >>>>> >>>>> _________________________________________ >>>>> 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> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Find and fix application performance issues faster with Applications >>>> Manager >>>> Applications Manager provides deep performance insights into multiple >>>> tiers of >>>> your business applications. It resolves application problems quickly >>>> and >>>> reduces your MTTR. Get your free trial! >>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >>>> <https://ad.doubleclick.net/ddm/clk/302982198;130105516;z> >>>> >>>> _________________________________________ >>>> 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> >>> >>> ------------------------------------------------------------------------------ >>> Find and fix application performance issues faster with Applications >>> Manager >>> Applications Manager provides deep performance insights into multiple >>> tiers of >>> your business applications. It resolves application problems quickly and >>> reduces your MTTR. Get your free trial! >>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_________________________________________ >>> moosefs-users mailing list >>> moo...@li... >>> https://lists.sourceforge.net/lists/listinfo/moosefs-users >> >> > > > ++++++++++++++++++++++++++++++++++++++++ > Valeri Galtsev > Sr System Administrator > Department of Astronomy and Astrophysics > Kavli Institute for Cosmological Physics > University of Chicago > Phone: 773-702-4247 > ++++++++++++++++++++++++++++++++++++++++ |
|
From: Valeri G. <ga...@ki...> - 2016-04-27 20:37:13
|
Thank you, gentlemen! Valeri On Wed, April 27, 2016 1:44 pm, Piotr Robert Konopelko wrote: > Dear Valeri, > > I'd like to let you know, that we've just released MooseFS 2.0.89 with > fix. > > Corresponding commit: > https://github.com/moosefs/moosefs/commit/b0125cf44cb40cc48d5b730088180654a0c8329c > <https://github.com/moosefs/moosefs/commit/b0125cf44cb40cc48d5b730088180654a0c8329c> > > > You can download it as follows: > > Packages for FreeBSD - from our website: > https://moosefs.com/download/freebsd.html > <https://moosefs.com/download/freebsd.html> > Sources - from our website: https://moosefs.com/download/sources.html > <https://moosefs.com/download/sources.html> > Sources - from GitHub: https://github.com/moosefs/moosefs/tree/2.0.x > <https://github.com/moosefs/moosefs/tree/2.0.x> > > > I'm going to update official ports in FreeBSD ports collection today, so > they should be available in a few days. > > Best regards, > > -- > > <https://moosefs.com/> > Piotr Robert Konopelko > MooseFS Technical Support Engineer > e-mail : pio...@mo... <mailto:pio...@mo...> > www : https://moosefs.com <https://moosefs.com/> > <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> > <https://www.linkedin.com/company/moosefs> > <https://github.com/moosefs> > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received it by mistake, please let us know by e-mail reply and > delete it from your system; you may not copy this message or disclose its > contents to anyone. Finally, the recipient should check this email and any > attachments for the presence of viruses. Core Technology accepts no > liability for any damage caused by any virus transmitted by this email. > > >> On 27 Apr 2016, at 2:58 PM, Aleksander Wieliczko >> <ale...@mo...> wrote: >> >> Hi Valeri, >> >> I would like to tell you that this strange behaviour is connected with >> FreeBSD kernel not with MooseFS. >> >> Mainly FreeBSD kernel sending setattr command before first close. >> Today we will publish MooseFS 2.0.89 packages with fix for FreeBSD >> kernel. >> >> After upgrade please let us know if all is working correctly. >> >> Best regards >> Aleksander Wieliczko >> Technical Support Engineer >> MooseFS.com <x-msg://14/moosefs.com> >> >> >> >> On 04/25/2016 02:07 PM, Aleksander Wieliczko wrote: >>> Hi Valeri, >>> >>> Excuse me. >>> I missed you previous mail. >>> >>> Right now I will test this issue on FreeBSD 9.3 >>> >>> Best regards >>> Aleksander Wieliczko >>> Technical Support Engineer >>> MooseFS.com <x-msg://14/moosefs.com> >>> >>> On 04/25/2016 01:46 PM, Aleksander Wieliczko wrote: >>>> Hi Valeri, >>>> >>>> I would like to inform you that we have made simple test in our >>>> development environment, and we do not observe such a behaviour. >>>> This is what we have: >>>> >>>> FreeBSD 10.2 >>>> MFS version 2.0.88-1 >>>> FUSE library version: 2.9.5 >>>> >>>> root@freebsd:~ # stat /mnt/mfs/test/* >>>> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:19:41 2016" "Apr >>>> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test1 >>>> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:23:26 2016" "Apr >>>> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test2 >>>> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:23:50 2016" "Apr >>>> 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test3 >>>> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:23:58 2016" "Apr >>>> 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test4 >>>> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:24:07 2016" "Apr >>>> 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test5 >>>> >>>> root@freebsd:~ # rsync -avu /mnt/mfs/test /tmp/ >>>> >>>> root@freebsd:~ # stat /mnt/mfs/test/* >>>> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:31:36 2016" "Apr >>>> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test1 >>>> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:31:36 2016" "Apr >>>> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test2 >>>> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:31:36 2016" "Apr >>>> 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test3 >>>> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:31:36 2016" "Apr >>>> 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test4 >>>> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:31:36 2016" "Apr >>>> 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 >>>> 0 /mnt/mfs/test/test5 >>>> >>>> You see, that only atime has been changed. >>>> >>>> Question is which FreeBSD version you have? >>>> >>>> I'm looking forward to hearing from you. >>>> Aleksander Wieliczko >>>> Technical Support Engineer >>>> MooseFS.com <x-msg://14/moosefs.com> >>>> >>>> >>>> On 04/22/2016 07:03 AM, Jakub Kruszona-Zawadzki wrote: >>>>> On 21 Apr, 2016, at 16:33, Valeri Galtsev <ga...@ki...> >>>>> <mailto:ga...@ki...> wrote: >>>>> >>>>>> Dear Experts, >>>>>> >>>>>> I have sort of weirdness I just stumbled over. >>>>>> >>>>>> I migrates some directories to moosefs (free opes source version, >>>>>> standard >>>>>> installation "by the book" on FreeBSD). At some point I decided to >>>>>> migrate >>>>>> the directory back to local (UFS) filesystem on the machine. Here is >>>>>> weirdness I observe: >>>>>> >>>>>> after i run >>>>>> >>>>>> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs >>>>>> >>>>>> I do get the content of directory on local filesystem as expected >>>>>> with all >>>>>> correct file attributes (user/group ownership, creation time, >>>>>> content). >>>>>> However, the source files on moosefs change their time stamps, as if >>>>>> the >>>>>> report last access time instead of creation time. They were >>>>>> reporting >>>>>> correct creation times after they were rsync'ed from local >>>>>> filesystem to >>>>>> moosefs originally. This basically renders rsync command useless >>>>>> (and >>>>>> damaging if you care about file creation times) when you rsync from >>>>>> moosefs (elsewhere). >>>>>> >>>>>> What am I doing wrong? I've used Linux and Unix for over decade an a >>>>>> half, >>>>>> ans used rsync over comparable period of time. What I hit with >>>>>> moosefs >>>>>> gives me kind of shock, and I can't figure myself what could I be >>>>>> doing >>>>>> wrong. >>>>>> >>>>>> Thanks in advance for all your advices. >>>>>> >>>>>> Valeri >>>>> We have changed atime/mtime management in MooseFS recently (in >>>>> version 3.0.74), so the question is which version of MooseFS do you >>>>> use? >>>>> >>>>> It looks like a bug in MooseFS, so we need the version, because we >>>>> have two options here. >>>>> The bug was in previous atime/mtime mechanism (pre 3.0.74) or there >>>>> is a bug in current mechanism. >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Find and fix application performance issues faster with Applications >>>> Manager >>>> Applications Manager provides deep performance insights into multiple >>>> tiers of >>>> your business applications. It resolves application problems quickly >>>> and >>>> reduces your MTTR. Get your free trial! >>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >>>> <https://ad.doubleclick.net/ddm/clk/302982198;130105516;z> >>>> >>>> _________________________________________ >>>> 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> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Find and fix application performance issues faster with Applications >>> Manager >>> Applications Manager provides deep performance insights into multiple >>> tiers of >>> your business applications. It resolves application problems quickly >>> and >>> reduces your MTTR. Get your free trial! >>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >>> <https://ad.doubleclick.net/ddm/clk/302982198;130105516;z> >>> >>> _________________________________________ >>> 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> >> >> ------------------------------------------------------------------------------ >> Find and fix application performance issues faster with Applications >> Manager >> Applications Manager provides deep performance insights into multiple >> tiers of >> your business applications. It resolves application problems quickly and >> reduces your MTTR. Get your free trial! >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ |
|
From: Piotr R. K. <pio...@mo...> - 2016-04-27 18:45:00
|
Dear Valeri, I'd like to let you know, that we've just released MooseFS 2.0.89 with fix. Corresponding commit: https://github.com/moosefs/moosefs/commit/b0125cf44cb40cc48d5b730088180654a0c8329c <https://github.com/moosefs/moosefs/commit/b0125cf44cb40cc48d5b730088180654a0c8329c> You can download it as follows: Packages for FreeBSD - from our website: https://moosefs.com/download/freebsd.html <https://moosefs.com/download/freebsd.html> Sources - from our website: https://moosefs.com/download/sources.html <https://moosefs.com/download/sources.html> Sources - from GitHub: https://github.com/moosefs/moosefs/tree/2.0.x <https://github.com/moosefs/moosefs/tree/2.0.x> I'm going to update official ports in FreeBSD ports collection today, so they should be available in a few days. Best regards, -- <https://moosefs.com/> Piotr Robert Konopelko MooseFS Technical Support Engineer e-mail : pio...@mo... <mailto:pio...@mo...> www : https://moosefs.com <https://moosefs.com/> <https://twitter.com/MooseFS> <https://www.facebook.com/moosefs> <https://www.linkedin.com/company/moosefs> <https://github.com/moosefs> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Finally, the recipient should check this email and any attachments for the presence of viruses. Core Technology accepts no liability for any damage caused by any virus transmitted by this email. > On 27 Apr 2016, at 2:58 PM, Aleksander Wieliczko <ale...@mo...> wrote: > > Hi Valeri, > > I would like to tell you that this strange behaviour is connected with FreeBSD kernel not with MooseFS. > > Mainly FreeBSD kernel sending setattr command before first close. > Today we will publish MooseFS 2.0.89 packages with fix for FreeBSD kernel. > > After upgrade please let us know if all is working correctly. > > Best regards > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <x-msg://14/moosefs.com> > > > > On 04/25/2016 02:07 PM, Aleksander Wieliczko wrote: >> Hi Valeri, >> >> Excuse me. >> I missed you previous mail. >> >> Right now I will test this issue on FreeBSD 9.3 >> >> Best regards >> Aleksander Wieliczko >> Technical Support Engineer >> MooseFS.com <x-msg://14/moosefs.com> >> >> On 04/25/2016 01:46 PM, Aleksander Wieliczko wrote: >>> Hi Valeri, >>> >>> I would like to inform you that we have made simple test in our development environment, and we do not observe such a behaviour. >>> This is what we have: >>> >>> FreeBSD 10.2 >>> MFS version 2.0.88-1 >>> FUSE library version: 2.9.5 >>> >>> root@freebsd:~ # stat /mnt/mfs/test/* >>> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test1 >>> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test2 >>> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test3 >>> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test4 >>> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test5 >>> >>> root@freebsd:~ # rsync -avu /mnt/mfs/test /tmp/ >>> >>> root@freebsd:~ # stat /mnt/mfs/test/* >>> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:31:36 2016" "Apr 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test1 >>> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:31:36 2016" "Apr 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test2 >>> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:31:36 2016" "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test3 >>> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:31:36 2016" "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test4 >>> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:31:36 2016" "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test5 >>> >>> You see, that only atime has been changed. >>> >>> Question is which FreeBSD version you have? >>> >>> I'm looking forward to hearing from you. >>> Aleksander Wieliczko >>> Technical Support Engineer >>> MooseFS.com <x-msg://14/moosefs.com> >>> >>> >>> On 04/22/2016 07:03 AM, Jakub Kruszona-Zawadzki wrote: >>>> On 21 Apr, 2016, at 16:33, Valeri Galtsev <ga...@ki...> <mailto:ga...@ki...> wrote: >>>> >>>>> Dear Experts, >>>>> >>>>> I have sort of weirdness I just stumbled over. >>>>> >>>>> I migrates some directories to moosefs (free opes source version, standard >>>>> installation "by the book" on FreeBSD). At some point I decided to migrate >>>>> the directory back to local (UFS) filesystem on the machine. Here is >>>>> weirdness I observe: >>>>> >>>>> after i run >>>>> >>>>> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs >>>>> >>>>> I do get the content of directory on local filesystem as expected with all >>>>> correct file attributes (user/group ownership, creation time, content). >>>>> However, the source files on moosefs change their time stamps, as if the >>>>> report last access time instead of creation time. They were reporting >>>>> correct creation times after they were rsync'ed from local filesystem to >>>>> moosefs originally. This basically renders rsync command useless (and >>>>> damaging if you care about file creation times) when you rsync from >>>>> moosefs (elsewhere). >>>>> >>>>> What am I doing wrong? I've used Linux and Unix for over decade an a half, >>>>> ans used rsync over comparable period of time. What I hit with moosefs >>>>> gives me kind of shock, and I can't figure myself what could I be doing >>>>> wrong. >>>>> >>>>> Thanks in advance for all your advices. >>>>> >>>>> Valeri >>>> We have changed atime/mtime management in MooseFS recently (in version 3.0.74), so the question is which version of MooseFS do you use? >>>> >>>> It looks like a bug in MooseFS, so we need the version, because we have two options here. >>>> The bug was in previous atime/mtime mechanism (pre 3.0.74) or there is a bug in current mechanism. >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Find and fix application performance issues faster with Applications Manager >>> Applications Manager provides deep performance insights into multiple tiers of >>> your business applications. It resolves application problems quickly and >>> reduces your MTTR. Get your free trial! >>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z <https://ad.doubleclick.net/ddm/clk/302982198;130105516;z> >>> >>> _________________________________________ >>> 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> >> >> >> >> ------------------------------------------------------------------------------ >> Find and fix application performance issues faster with Applications Manager >> Applications Manager provides deep performance insights into multiple tiers of >> your business applications. It resolves application problems quickly and >> reduces your MTTR. Get your free trial! >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z <https://ad.doubleclick.net/ddm/clk/302982198;130105516;z> >> >> _________________________________________ >> 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> > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Aleksander W. <ale...@mo...> - 2016-04-27 12:58:37
|
Hi Valeri, I would like to tell you that this strange behaviour is connected with FreeBSD kernel not with MooseFS. Mainly FreeBSD kernel sending setattr command before first close. Today we will publish MooseFS 2.0.89 packages with fix for FreeBSD kernel. After upgrade please let us know if all is working correctly. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 04/25/2016 02:07 PM, Aleksander Wieliczko wrote: > Hi Valeri, > > Excuse me. > I missed you previous mail. > > Right now I will test this issue on FreeBSD 9.3 > > Best regards > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <moosefs.com> > > On 04/25/2016 01:46 PM, Aleksander Wieliczko wrote: >> Hi Valeri, >> >> I would like to inform you that we have made simple test in our >> development environment, and we do not observe such a behaviour. >> This is what we have: >> >> FreeBSD 10.2 >> MFS version 2.0.88-1 >> FUSE library version: 2.9.5 >> >> root@freebsd:~ # stat /mnt/mfs/test/* >> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:19:41 2016" "Apr >> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 >> 1 0 /mnt/mfs/test/test1 >> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:23:26 2016" "Apr >> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 >> 1 0 /mnt/mfs/test/test2 >> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:23:50 2016" >> "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test3 >> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:23:58 2016" >> "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test4 >> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:24:07 2016" >> "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test5 >> >> root@freebsd:~ # rsync -avu /mnt/mfs/test /tmp/ >> >> root@freebsd:~ # stat /mnt/mfs/test/* >> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:31:36 2016" "Apr >> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 >> 1 0 /mnt/mfs/test/test1 >> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:31:36 2016" "Apr >> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 >> 1 0 /mnt/mfs/test/test2 >> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:31:36 2016" >> "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test3 >> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:31:36 2016" >> "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test4 >> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:31:36 2016" >> "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test5 >> >> You see, that only atime has been changed. >> >> Question is which FreeBSD version you have? >> >> I'm looking forward to hearing from you. >> Aleksander Wieliczko >> Technical Support Engineer >> MooseFS.com <moosefs.com> >> >> >> On 04/22/2016 07:03 AM, Jakub Kruszona-Zawadzki wrote: >>> On 21 Apr, 2016, at 16:33, Valeri Galtsev <ga...@ki...> wrote: >>> >>>> Dear Experts, >>>> >>>> I have sort of weirdness I just stumbled over. >>>> >>>> I migrates some directories to moosefs (free opes source version, standard >>>> installation "by the book" on FreeBSD). At some point I decided to migrate >>>> the directory back to local (UFS) filesystem on the machine. Here is >>>> weirdness I observe: >>>> >>>> after i run >>>> >>>> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs >>>> >>>> I do get the content of directory on local filesystem as expected with all >>>> correct file attributes (user/group ownership, creation time, content). >>>> However, the source files on moosefs change their time stamps, as if the >>>> report last access time instead of creation time. They were reporting >>>> correct creation times after they were rsync'ed from local filesystem to >>>> moosefs originally. This basically renders rsync command useless (and >>>> damaging if you care about file creation times) when you rsync from >>>> moosefs (elsewhere). >>>> >>>> What am I doing wrong? I've used Linux and Unix for over decade an a half, >>>> ans used rsync over comparable period of time. What I hit with moosefs >>>> gives me kind of shock, and I can't figure myself what could I be doing >>>> wrong. >>>> >>>> Thanks in advance for all your advices. >>>> >>>> Valeri >>> We have changed atime/mtime management in MooseFS recently (in version 3.0.74), so the question is which version of MooseFS do you use? >>> >>> It looks like a bug in MooseFS, so we need the version, because we have two options here. >>> The bug was in previous atime/mtime mechanism (pre 3.0.74) or there is a bug in current mechanism. >>> >> >> >> >> ------------------------------------------------------------------------------ >> Find and fix application performance issues faster with Applications Manager >> Applications Manager provides deep performance insights into multiple tiers of >> your business applications. It resolves application problems quickly and >> reduces your MTTR. Get your free trial! >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> >> >> _________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > > > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Aleksander W. <ale...@mo...> - 2016-04-25 14:05:26
|
Hi, I would like to add that we repeated this issue in our development environment. This is very strange MooseFS behaviour. We are starting debugging process so we will inform you about progress. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 04/25/2016 02:07 PM, Aleksander Wieliczko wrote: > Hi Valeri, > > Excuse me. > I missed you previous mail. > > Right now I will test this issue on FreeBSD 9.3 > > Best regards > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <moosefs.com> > > On 04/25/2016 01:46 PM, Aleksander Wieliczko wrote: >> Hi Valeri, >> >> I would like to inform you that we have made simple test in our >> development environment, and we do not observe such a behaviour. >> This is what we have: >> >> FreeBSD 10.2 >> MFS version 2.0.88-1 >> FUSE library version: 2.9.5 >> >> root@freebsd:~ # stat /mnt/mfs/test/* >> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:19:41 2016" "Apr >> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 >> 1 0 /mnt/mfs/test/test1 >> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:23:26 2016" "Apr >> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 >> 1 0 /mnt/mfs/test/test2 >> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:23:50 2016" >> "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test3 >> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:23:58 2016" >> "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test4 >> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:24:07 2016" >> "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test5 >> >> root@freebsd:~ # rsync -avu /mnt/mfs/test /tmp/ >> >> root@freebsd:~ # stat /mnt/mfs/test/* >> 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:31:36 2016" "Apr >> 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 >> 1 0 /mnt/mfs/test/test1 >> 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:31:36 2016" "Apr >> 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 >> 1 0 /mnt/mfs/test/test2 >> 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:31:36 2016" >> "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test3 >> 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:31:36 2016" >> "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test4 >> 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:31:36 2016" >> "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" >> 4096 1 0 /mnt/mfs/test/test5 >> >> You see, that only atime has been changed. >> >> Question is which FreeBSD version you have? >> >> I'm looking forward to hearing from you. >> Aleksander Wieliczko >> Technical Support Engineer >> MooseFS.com <moosefs.com> >> >> >> On 04/22/2016 07:03 AM, Jakub Kruszona-Zawadzki wrote: >>> On 21 Apr, 2016, at 16:33, Valeri Galtsev <ga...@ki...> wrote: >>> >>>> Dear Experts, >>>> >>>> I have sort of weirdness I just stumbled over. >>>> >>>> I migrates some directories to moosefs (free opes source version, standard >>>> installation "by the book" on FreeBSD). At some point I decided to migrate >>>> the directory back to local (UFS) filesystem on the machine. Here is >>>> weirdness I observe: >>>> >>>> after i run >>>> >>>> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs >>>> >>>> I do get the content of directory on local filesystem as expected with all >>>> correct file attributes (user/group ownership, creation time, content). >>>> However, the source files on moosefs change their time stamps, as if the >>>> report last access time instead of creation time. They were reporting >>>> correct creation times after they were rsync'ed from local filesystem to >>>> moosefs originally. This basically renders rsync command useless (and >>>> damaging if you care about file creation times) when you rsync from >>>> moosefs (elsewhere). >>>> >>>> What am I doing wrong? I've used Linux and Unix for over decade an a half, >>>> ans used rsync over comparable period of time. What I hit with moosefs >>>> gives me kind of shock, and I can't figure myself what could I be doing >>>> wrong. >>>> >>>> Thanks in advance for all your advices. >>>> >>>> Valeri >>> We have changed atime/mtime management in MooseFS recently (in version 3.0.74), so the question is which version of MooseFS do you use? >>> >>> It looks like a bug in MooseFS, so we need the version, because we have two options here. >>> The bug was in previous atime/mtime mechanism (pre 3.0.74) or there is a bug in current mechanism. >>> >> >> >> >> ------------------------------------------------------------------------------ >> Find and fix application performance issues faster with Applications Manager >> Applications Manager provides deep performance insights into multiple tiers of >> your business applications. It resolves application problems quickly and >> reduces your MTTR. Get your free trial! >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> >> >> _________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > > > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Aleksander W. <ale...@mo...> - 2016-04-25 12:07:59
|
Hi Valeri, Excuse me. I missed you previous mail. Right now I will test this issue on FreeBSD 9.3 Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 04/25/2016 01:46 PM, Aleksander Wieliczko wrote: > Hi Valeri, > > I would like to inform you that we have made simple test in our > development environment, and we do not observe such a behaviour. > This is what we have: > > FreeBSD 10.2 > MFS version 2.0.88-1 > FUSE library version: 2.9.5 > > root@freebsd:~ # stat /mnt/mfs/test/* > 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:19:41 2016" "Apr > 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test1 > 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:23:26 2016" "Apr > 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test2 > 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:23:50 2016" "Apr > 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test3 > 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:23:58 2016" "Apr > 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test4 > 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:24:07 2016" "Apr > 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test5 > > root@freebsd:~ # rsync -avu /mnt/mfs/test /tmp/ > > root@freebsd:~ # stat /mnt/mfs/test/* > 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:31:36 2016" "Apr > 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test1 > 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:31:36 2016" "Apr > 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test2 > 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:31:36 2016" "Apr > 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test3 > 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:31:36 2016" "Apr > 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test4 > 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:31:36 2016" "Apr > 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 > 0 /mnt/mfs/test/test5 > > You see, that only atime has been changed. > > Question is which FreeBSD version you have? > > I'm looking forward to hearing from you. > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <moosefs.com> > > > On 04/22/2016 07:03 AM, Jakub Kruszona-Zawadzki wrote: >> On 21 Apr, 2016, at 16:33, Valeri Galtsev <ga...@ki...> wrote: >> >>> Dear Experts, >>> >>> I have sort of weirdness I just stumbled over. >>> >>> I migrates some directories to moosefs (free opes source version, standard >>> installation "by the book" on FreeBSD). At some point I decided to migrate >>> the directory back to local (UFS) filesystem on the machine. Here is >>> weirdness I observe: >>> >>> after i run >>> >>> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs >>> >>> I do get the content of directory on local filesystem as expected with all >>> correct file attributes (user/group ownership, creation time, content). >>> However, the source files on moosefs change their time stamps, as if the >>> report last access time instead of creation time. They were reporting >>> correct creation times after they were rsync'ed from local filesystem to >>> moosefs originally. This basically renders rsync command useless (and >>> damaging if you care about file creation times) when you rsync from >>> moosefs (elsewhere). >>> >>> What am I doing wrong? I've used Linux and Unix for over decade an a half, >>> ans used rsync over comparable period of time. What I hit with moosefs >>> gives me kind of shock, and I can't figure myself what could I be doing >>> wrong. >>> >>> Thanks in advance for all your advices. >>> >>> Valeri >> We have changed atime/mtime management in MooseFS recently (in version 3.0.74), so the question is which version of MooseFS do you use? >> >> It looks like a bug in MooseFS, so we need the version, because we have two options here. >> The bug was in previous atime/mtime mechanism (pre 3.0.74) or there is a bug in current mechanism. >> > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > > > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Aleksander W. <ale...@mo...> - 2016-04-25 11:46:46
|
Hi Valeri, I would like to inform you that we have made simple test in our development environment, and we do not observe such a behaviour. This is what we have: FreeBSD 10.2 MFS version 2.0.88-1 FUSE library version: 2.9.5 root@freebsd:~ # stat /mnt/mfs/test/* 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test1 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test2 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test3 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test4 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test5 root@freebsd:~ # rsync -avu /mnt/mfs/test /tmp/ root@freebsd:~ # stat /mnt/mfs/test/* 3976265473 8 -rw-r--r-- 1 root wheel 0 11 "Apr 25 13:31:36 2016" "Apr 25 13:19:41 2016" "Apr 25 13:19:41 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test1 3976265473 9 -rw-r--r-- 1 root wheel 0 19 "Apr 25 13:31:36 2016" "Apr 25 13:23:26 2016" "Apr 25 13:23:26 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test2 3976265473 10 -rw-r--r-- 1 root wheel 0 20 "Apr 25 13:31:36 2016" "Apr 25 13:23:50 2016" "Apr 25 13:23:50 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test3 3976265473 11 -rw-r--r-- 1 root wheel 0 34 "Apr 25 13:31:36 2016" "Apr 25 13:23:58 2016" "Apr 25 13:23:58 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test4 3976265473 12 -rw-r--r-- 1 root wheel 0 45 "Apr 25 13:31:36 2016" "Apr 25 13:24:07 2016" "Apr 25 13:24:07 2016" "Jan 1 00:59:59 1970" 4096 1 0 /mnt/mfs/test/test5 You see, that only atime has been changed. Question is which FreeBSD version you have? I'm looking forward to hearing from you. Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 04/22/2016 07:03 AM, Jakub Kruszona-Zawadzki wrote: > On 21 Apr, 2016, at 16:33, Valeri Galtsev <ga...@ki...> wrote: > >> Dear Experts, >> >> I have sort of weirdness I just stumbled over. >> >> I migrates some directories to moosefs (free opes source version, standard >> installation "by the book" on FreeBSD). At some point I decided to migrate >> the directory back to local (UFS) filesystem on the machine. Here is >> weirdness I observe: >> >> after i run >> >> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs >> >> I do get the content of directory on local filesystem as expected with all >> correct file attributes (user/group ownership, creation time, content). >> However, the source files on moosefs change their time stamps, as if the >> report last access time instead of creation time. They were reporting >> correct creation times after they were rsync'ed from local filesystem to >> moosefs originally. This basically renders rsync command useless (and >> damaging if you care about file creation times) when you rsync from >> moosefs (elsewhere). >> >> What am I doing wrong? I've used Linux and Unix for over decade an a half, >> ans used rsync over comparable period of time. What I hit with moosefs >> gives me kind of shock, and I can't figure myself what could I be doing >> wrong. >> >> Thanks in advance for all your advices. >> >> Valeri > We have changed atime/mtime management in MooseFS recently (in version 3.0.74), so the question is which version of MooseFS do you use? > > It looks like a bug in MooseFS, so we need the version, because we have two options here. > The bug was in previous atime/mtime mechanism (pre 3.0.74) or there is a bug in current mechanism. > |
|
From: Valeri G. <ga...@ki...> - 2016-04-22 14:41:14
|
On Fri, April 22, 2016 12:03 am, Jakub Kruszona-Zawadzki wrote: > > On 21 Apr, 2016, at 16:33, Valeri Galtsev <ga...@ki...> > wrote: > >> Dear Experts, >> >> I have sort of weirdness I just stumbled over. >> >> I migrates some directories to moosefs (free opes source version, >> standard >> installation "by the book" on FreeBSD). At some point I decided to >> migrate >> the directory back to local (UFS) filesystem on the machine. Here is >> weirdness I observe: >> >> after i run >> >> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs >> >> I do get the content of directory on local filesystem as expected with >> all >> correct file attributes (user/group ownership, creation time, content). >> However, the source files on moosefs change their time stamps, as if the >> report last access time instead of creation time. They were reporting >> correct creation times after they were rsync'ed from local filesystem to >> moosefs originally. This basically renders rsync command useless (and >> damaging if you care about file creation times) when you rsync from >> moosefs (elsewhere). >> >> What am I doing wrong? I've used Linux and Unix for over decade an a >> half, >> ans used rsync over comparable period of time. What I hit with moosefs >> gives me kind of shock, and I can't figure myself what could I be doing >> wrong. >> >> Thanks in advance for all your advices. >> >> Valeri > > We have changed atime/mtime management in MooseFS recently (in version > 3.0.74), so the question is which version of MooseFS do you use? > > It looks like a bug in MooseFS, so we need the version, because we have > two options here. > The bug was in previous atime/mtime mechanism (pre 3.0.74) or there is a > bug in current mechanism. It is open source [valeri@felix ~]$ pkg info -a | grep moose moosefs-cgi-2.0.88 MooseFS CGI interface moosefs-cgiserv-2.0.88 MooseFS CGI webserver moosefs-chunkserver-2.0.88 MooseFS data storage and synchronization component moosefs-cli-2.0.88 MooseFS command line interface moosefs-client-2.0.88 MooseFS client tools moosefs-master-2.0.88 Fault-tolerant distributed filesystem on FreeBSD: FreeBSD felix.uchicago.edu 9.3-RELEASE-p39 FreeBSD 9.3-RELEASE-p39 #0: Wed Mar 16 16:29:56 UTC 2016 ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 Thanks. Valeri > > -- > > \_\ /_/ > \_\_ _/_/ > \--/ > /Oo\_--____ > (__) ) > ``\ __ | > ||-~ `|| > || || > "" "" > > Regards, > Jakub Kruszona-Zawadzki > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ |
|
From: Jakub Kruszona-Z. <jak...@ge...> - 2016-04-22 05:30:40
|
On 21 Apr, 2016, at 16:33, Valeri Galtsev <ga...@ki...> wrote:
> Dear Experts,
>
> I have sort of weirdness I just stumbled over.
>
> I migrates some directories to moosefs (free opes source version, standard
> installation "by the book" on FreeBSD). At some point I decided to migrate
> the directory back to local (UFS) filesystem on the machine. Here is
> weirdness I observe:
>
> after i run
>
> rsync -avu /path/do/mfs/mount/directory /path/to/local/fs
>
> I do get the content of directory on local filesystem as expected with all
> correct file attributes (user/group ownership, creation time, content).
> However, the source files on moosefs change their time stamps, as if the
> report last access time instead of creation time. They were reporting
> correct creation times after they were rsync'ed from local filesystem to
> moosefs originally. This basically renders rsync command useless (and
> damaging if you care about file creation times) when you rsync from
> moosefs (elsewhere).
>
> What am I doing wrong? I've used Linux and Unix for over decade an a half,
> ans used rsync over comparable period of time. What I hit with moosefs
> gives me kind of shock, and I can't figure myself what could I be doing
> wrong.
>
> Thanks in advance for all your advices.
>
> Valeri
We have changed atime/mtime management in MooseFS recently (in version 3.0.74), so the question is which version of MooseFS do you use?
It looks like a bug in MooseFS, so we need the version, because we have two options here.
The bug was in previous atime/mtime mechanism (pre 3.0.74) or there is a bug in current mechanism.
--
\_\ /_/
\_\_ _/_/
\--/
/Oo\_--____
(__) )
``\ __ |
||-~ `||
|| ||
"" ""
Regards,
Jakub Kruszona-Zawadzki
|
84 messages has been excluded from this view by a project administrator.
