Menu
▾
▴
Re: [MooseFS-Users] rsync from moosfs chnages source file time stamps
|
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 ++++++++++++++++++++++++++++++++++++++++ |
