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: Wilson, S. M <st...@pu...> - 2016-09-12 13:28:17
|
?Hi Aleksander, Thanks for attempting to reproduce the problem in your environment. I'll send the mfsexports.cfg files to you (prior to the change and after the change). I use Ansible for configuration management and I normally make all changes on my Ansible server in a file of my own format that is then used to build mfsexports.cfg files on each MooseFS master server. So I'll also send the script that Ansible calls to build the mfsexports.cfg file and issue a HUP signal to mfsmaster. Thanks, Steve ________________________________ From: Aleksander Wieliczko <ale...@mo...> Sent: Monday, September 12, 2016 6:25 AM To: Wilson, Steven M; Krzysztof Kielak Cc: MooseFS-Users Subject: Re: [MooseFS-Users] mfsmaster config reload breaks client mounts? Hi, I would like to inform you that we are not able to reproduce this problem in our development environment. Also I would like to add that in MooseFS is scenario which can cause mfsmount session drop. When you change permissions in mfsexports.cfg file for connected mounts and you send HUP signal, MooseFS master will check permissions again, and if permissions have been changed access to cluster will be denied. We have another question for you. Can you send us old and new "mfsexports.cfg" files, so we will be able to understand what had happened? You can send it to dwt[at]moosefs.com Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com<moosefs.com> |
|
From: Aleksander W. <ale...@mo...> - 2016-09-12 10:25:22
|
Hi, I would like to inform you that we are not able to reproduce this problem in our development environment. Also I would like to add that in MooseFS is scenario which can cause mfsmount session drop. When you change permissions in mfsexports.cfg file for connected mounts and you send HUP signal, MooseFS master will check permissions again, and if permissions have been changed access to cluster will be denied. We have another question for you. Can you send us old and new "mfsexports.cfg" files, so we will be able to understand what had happened? You can send itto dwt[at]moosefs.com Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> |
|
From: Wilson, S. M <st...@pu...> - 2016-09-10 00:29:28
|
Hi Krzysztof, Thanks for trying to replicate the problem in your environment. The only change that I made (that I'm aware of) was adding another client to mfsexports.cfg. Best regards, Steve On Sep 9, 2016 6:30 PM, Krzysztof Kielak <krz...@mo...> wrote: Hi Steven, We’ll try to replicate this problem in our lab environment next week and get back to you and the list with our findings. Can you please describe in more details what kind of changes you’ve made to mfsexports.cfg? Best Regards, Krzysztof Kielak Moosefs.com<http://moosefs.com> | Director of Operations and Customer Support Mobile: +48 601 476 440 On 09 Sep 2016, at 22:36, Wilson, Steven M <st...@pu...<mailto:st...@pu...>> wrote: Hi, Earlier today I made a change to mfsexports.cfg and then forced mfsmaster to perform a configuration reload by sending a HUP signal to the mfsmaster process. At that point, all my client MooseFS mounts became empty. The mount points were still in /proc/self/mountinfo and it looks like any open files were still accessible. But to make the MooseFS filesystem visible and accessible again, I had to unmount it and then mount it again on each of my clients. I've made changes to mfsexports.cfg and forced mfsmaster to reload in the past (probably when I was still using MooseFS 2.x) but I never had a problem like this. I'm using version 3.0.81. Has anyone else seen this? I don't have a test environment to try this again otherwise I would do it again and make sure that it's repeatable and not just some strange but rare fluke. Thanks! Steve ------------------------------------------------------------------------------ _________________________________________ moosefs-users mailing list moo...@li...<mailto:moo...@li...> https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Krzysztof K. <krz...@mo...> - 2016-09-09 22:31:01
|
Hi Steven, We’ll try to replicate this problem in our lab environment next week and get back to you and the list with our findings. Can you please describe in more details what kind of changes you’ve made to mfsexports.cfg? Best Regards, Krzysztof Kielak Moosefs.com | Director of Operations and Customer Support Mobile: +48 601 476 440 > On 09 Sep 2016, at 22:36, Wilson, Steven M <st...@pu...> wrote: > > Hi, > > Earlier today I made a change to mfsexports.cfg and then forced mfsmaster to perform a configuration reload by sending a HUP signal to the mfsmaster process. At that point, all my client MooseFS mounts became empty. The mount points were still in /proc/self/mountinfo and it looks like any open files were still accessible. But to make the MooseFS filesystem visible and accessible again, I had to unmount it and then mount it again on each of my clients. I've made changes to mfsexports.cfg and forced mfsmaster to reload in the past (probably when I was still using MooseFS 2.x) but I never had a problem like this. I'm using version 3.0.81. Has anyone else seen this? I don't have a test environment to try this again otherwise I would do it again and make sure that it's repeatable and not just some strange but rare fluke. > > Thanks! > > Steve > ------------------------------------------------------------------------------ > _________________________________________ > 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> |
|
From: Wilson, S. M <st...@pu...> - 2016-09-09 20:37:01
|
?Hi, Earlier today I made a change to mfsexports.cfg and then forced mfsmaster to perform a configuration reload by sending a HUP signal to the mfsmaster process. At that point, all my client MooseFS mounts became empty. The mount points were still in /proc/self/mountinfo and it looks like any open files were still accessible. But to make the MooseFS filesystem visible and accessible again, I had to unmount it and then mount it again on each of my clients. I've made changes to mfsexports.cfg and forced mfsmaster to reload in the past (probably when I was still using MooseFS 2.x) but I never had a problem like this. I'm using version 3.0.81. Has anyone else seen this? I don't have a test environment to try this again otherwise I would do it again and make sure that it's repeatable and not just some strange but rare fluke. Thanks! Steve |
|
From: Piotr R. K. <pio...@mo...> - 2016-09-01 11:14:34
|
> On 01 Sep 2016, at 12:43 PM, Tom Ivar Helbekkmo <ti...@ha...> wrote: > > Funny typo in the man page: "mfsdiagtools - NooseFS diagnostic tools". :) Haha :) I think unfortunately we'll fix it :) Peter -- Piotr Robert Konopelko MooseFS Technical Support Engineer | moosefs.com <https://moosefs.com/> |
|
From: Tom I. H. <ti...@ha...> - 2016-09-01 10:43:45
|
Paweł Kowalski <ma...@gm...> writes: > size: 214924626944 > realsize: 429849253888 > > But - if i copy this dir to harddrive : > > du -d 0 -h frontend_projekty/ > 197G frontend_projekty/ > > What is the reason for this difference ? You can add "-h" to the mfsdirinfo command, and get prettier numbers. You should find that the 'size' is just slightly larger in MooseFS. The 'realsize' is the double of 'size', because you're storing two copies of the data in MooseFS, thus using twice the physical storage capacity. Funny typo in the man page: "mfsdiagtools - NooseFS diagnostic tools". :) -tih -- Elections cannot be allowed to change anything. --Dr. Wolfgang Schäuble |
|
From: Paweł K. <ma...@gm...> - 2016-09-01 09:44:08
|
Hello, mfsdirinfo : mfsdirinfo -p frontend_projekty/ frontend_projekty/: inodes: 579036 directories: 290321 files: 288715 chunks: 288711 length: 201767005613 size: 214924626944 realsize: 429849253888 frontend_projekty/ (precise data): inodes: 579036 directories: 290321 files: 288715 chunks: 288711 length: 201767005613 size: 214924626944 realsize: 429849253888 But - if i copy this dir to harddrive : du -d 0 -h frontend_projekty/ 197G frontend_projekty/ What is the reason for this difference ? W dniu 2016-09-01 o 09:29, Aleksander Wieliczko pisze: > Hi, > > To calculate real size of folder in MooseFS please use mfsdirinfo with > -p parameter: > > "-p > > Precise mode means that system takes into account repeated nodes/chunks > and count them once, also uses current number of copies instead of goal." > > Best regards > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <moosefs.com> > > On 08/31/2016 11:23 PM, Alex Crow wrote: >> I am a bit concerned about this too, 979k from 80K with a single cp? >> >> Cheers >> >> Alex >> >> >> On 31/08/16 12:12, Tom Ivar Helbekkmo wrote: >>> I guess the surprise is what happens here (MooseFS 3.0.80): >>> >>> tih@thuvia:/usr/local/store/Data$ mkdir tmp >>> tih@thuvia:/usr/local/store/Data$ cd tmp >>> tih@thuvia:/usr/local/store/Data/tmp$ du -hs . >>> 0B . >>> tih@thuvia:/usr/local/store/Data/tmp$ dd if=/dev/zero of=file1 bs=1 count=800 >>> 800+0 records in >>> 800+0 records out >>> 800 bytes transferred in 0.672 secs (1190 bytes/sec) >>> tih@thuvia:/usr/local/store/Data/tmp$ du -hs * >>> 1.0K file1 >>> tih@thuvia:/usr/local/store/Data/tmp$ du -hs . >>> 80K . >>> tih@thuvia:/usr/local/store/Data/tmp$ cp file1 file2 >>> tih@thuvia:/usr/local/store/Data/tmp$ du -hs * >>> 1.0K file1 >>> 1.0K file2 >>> tih@thuvia:/usr/local/store/Data/tmp$ du -hs . >>> 979K . >>> tih@thuvia:/usr/local/store/Data/tmp$ >>> >>> -tih >> -- >> This message is intended only for the addressee and may contain >> confidential information. Unless you are that person, you may not >> disclose its contents or use it in any way and are requested to delete >> the message along with any attachments and notify us immediately. >> This email is not intended to, nor should it be taken to, constitute advice. >> The information provided is correct to our knowledge & belief and must not >> be used as a substitute for obtaining tax, regulatory, investment, legal or >> any other appropriate advice. >> >> "Transact" is operated by Integrated Financial Arrangements Ltd. >> 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. >> (Registered office: as above; Registered in England and Wales under >> number: 3727592). Authorised and regulated by the Financial Conduct >> Authority (entered on the Financial Services Register; no. 190856). >> >> ------------------------------------------------------------------------------ >> _________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > > ------------------------------------------------------------------------------ > > > > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users > -- Paweł "Argail" Kowalski "... krzesło pozostaje krzesłem, nawet kiedy nikt na nim nie siedzi ..." |
|
From: Aleksander W. <ale...@mo...> - 2016-09-01 07:29:30
|
Hi, To calculate real size of folder in MooseFS please use mfsdirinfo with -p parameter: "-p Precise mode means that system takes into account repeated nodes/chunks and count them once, also uses current number of copies instead of goal." Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 08/31/2016 11:23 PM, Alex Crow wrote: > I am a bit concerned about this too, 979k from 80K with a single cp? > > Cheers > > Alex > > > On 31/08/16 12:12, Tom Ivar Helbekkmo wrote: >> I guess the surprise is what happens here (MooseFS 3.0.80): >> >> tih@thuvia:/usr/local/store/Data$ mkdir tmp >> tih@thuvia:/usr/local/store/Data$ cd tmp >> tih@thuvia:/usr/local/store/Data/tmp$ du -hs . >> 0B . >> tih@thuvia:/usr/local/store/Data/tmp$ dd if=/dev/zero of=file1 bs=1 count=800 >> 800+0 records in >> 800+0 records out >> 800 bytes transferred in 0.672 secs (1190 bytes/sec) >> tih@thuvia:/usr/local/store/Data/tmp$ du -hs * >> 1.0K file1 >> tih@thuvia:/usr/local/store/Data/tmp$ du -hs . >> 80K . >> tih@thuvia:/usr/local/store/Data/tmp$ cp file1 file2 >> tih@thuvia:/usr/local/store/Data/tmp$ du -hs * >> 1.0K file1 >> 1.0K file2 >> tih@thuvia:/usr/local/store/Data/tmp$ du -hs . >> 979K . >> tih@thuvia:/usr/local/store/Data/tmp$ >> >> -tih > -- > This message is intended only for the addressee and may contain > confidential information. Unless you are that person, you may not > disclose its contents or use it in any way and are requested to delete > the message along with any attachments and notify us immediately. > This email is not intended to, nor should it be taken to, constitute advice. > The information provided is correct to our knowledge & belief and must not > be used as a substitute for obtaining tax, regulatory, investment, legal or > any other appropriate advice. > > "Transact" is operated by Integrated Financial Arrangements Ltd. > 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. > (Registered office: as above; Registered in England and Wales under > number: 3727592). Authorised and regulated by the Financial Conduct > Authority (entered on the Financial Services Register; no. 190856). > > ------------------------------------------------------------------------------ > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Alex C. <ac...@in...> - 2016-08-31 21:23:42
|
I am a bit concerned about this too, 979k from 80K with a single cp? Cheers Alex On 31/08/16 12:12, Tom Ivar Helbekkmo wrote: > I guess the surprise is what happens here (MooseFS 3.0.80): > > tih@thuvia:/usr/local/store/Data$ mkdir tmp > tih@thuvia:/usr/local/store/Data$ cd tmp > tih@thuvia:/usr/local/store/Data/tmp$ du -hs . > 0B . > tih@thuvia:/usr/local/store/Data/tmp$ dd if=/dev/zero of=file1 bs=1 count=800 > 800+0 records in > 800+0 records out > 800 bytes transferred in 0.672 secs (1190 bytes/sec) > tih@thuvia:/usr/local/store/Data/tmp$ du -hs * > 1.0K file1 > tih@thuvia:/usr/local/store/Data/tmp$ du -hs . > 80K . > tih@thuvia:/usr/local/store/Data/tmp$ cp file1 file2 > tih@thuvia:/usr/local/store/Data/tmp$ du -hs * > 1.0K file1 > 1.0K file2 > tih@thuvia:/usr/local/store/Data/tmp$ du -hs . > 979K . > tih@thuvia:/usr/local/store/Data/tmp$ > > -tih -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. This email is not intended to, nor should it be taken to, constitute advice. The information provided is correct to our knowledge & belief and must not be used as a substitute for obtaining tax, regulatory, investment, legal or any other appropriate advice. "Transact" is operated by Integrated Financial Arrangements Ltd. 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. (Registered office: as above; Registered in England and Wales under number: 3727592). Authorised and regulated by the Financial Conduct Authority (entered on the Financial Services Register; no. 190856). |
|
From: Tom I. H. <ti...@ha...> - 2016-08-31 11:30:36
|
I guess the surprise is what happens here (MooseFS 3.0.80): tih@thuvia:/usr/local/store/Data$ mkdir tmp tih@thuvia:/usr/local/store/Data$ cd tmp tih@thuvia:/usr/local/store/Data/tmp$ du -hs . 0B . tih@thuvia:/usr/local/store/Data/tmp$ dd if=/dev/zero of=file1 bs=1 count=800 800+0 records in 800+0 records out 800 bytes transferred in 0.672 secs (1190 bytes/sec) tih@thuvia:/usr/local/store/Data/tmp$ du -hs * 1.0K file1 tih@thuvia:/usr/local/store/Data/tmp$ du -hs . 80K . tih@thuvia:/usr/local/store/Data/tmp$ cp file1 file2 tih@thuvia:/usr/local/store/Data/tmp$ du -hs * 1.0K file1 1.0K file2 tih@thuvia:/usr/local/store/Data/tmp$ du -hs . 979K . tih@thuvia:/usr/local/store/Data/tmp$ -tih -- Elections cannot be allowed to change anything. --Dr. Wolfgang Schäuble |
|
From: Paweł K. <ma...@gm...> - 2016-08-31 10:40:07
|
Hello, Yes, i know about 64k chunk size, but that does not explain this situation. In "project" folder is many files (~230k) and many subdirs - i understand overhead ~50G, but 300G ? ".. .https://moosefs.com/documentation/faq.html#10 A more typical, medium to large project with 100,000 small files would consume at most 13GiB of extra space due to block size of used file system. ..." File size in folder "project" is from 2kB to 30MB, number of folders : 287469, number of files : 285819 W dniu 2016-08-31 o 10:16, Alex Crow pisze: > Hi, > > Does the folder have lots of small files? The minimum chunk size is 64k > so if you have files smaller than this you will have some amplification. > > Cheers > > Alex > > > On 31/08/16 08:35, Paweł Kowalski wrote: >> Hello, >> >> This is the case : >> >> mosefs 3.0.81, Ubuntu 14.04 as master and chunks, freebsd 10.2 as client: >> >> >> folder "project" >> :# du -sh project >> 191G project >> :# >> >> Ok, so we move to mosefs: >> >> >> :# mv -r project/ /mnt/moosefs/project >> :# >> >> after a while >> >> :# cd /mnt/moose/ >> :# du -sh project >> 509G project/ >> >> ?!?!?! for God's sake - why ???? >> >> :# mfsgetgoal * >> projects : 2 >> :# >> ..... >> Any ideas ? >> >> >> >> >> > -- > This message is intended only for the addressee and may contain > confidential information. Unless you are that person, you may not > disclose its contents or use it in any way and are requested to delete > the message along with any attachments and notify us immediately. > This email is not intended to, nor should it be taken to, constitute advice. > The information provided is correct to our knowledge & belief and must not > be used as a substitute for obtaining tax, regulatory, investment, legal or > any other appropriate advice. > > "Transact" is operated by Integrated Financial Arrangements Ltd. > 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. > (Registered office: as above; Registered in England and Wales under > number: 3727592). Authorised and regulated by the Financial Conduct > Authority (entered on the Financial Services Register; no. 190856). > > ------------------------------------------------------------------------------ > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users -- Paweł "Argail" Kowalski "... krzesło pozostaje krzesłem, nawet kiedy nikt na nim nie siedzi ..." |
|
From: Alex C. <ac...@in...> - 2016-08-31 08:34:00
|
Hi, Does the folder have lots of small files? The minimum chunk size is 64k so if you have files smaller than this you will have some amplification. Cheers Alex On 31/08/16 08:35, Paweł Kowalski wrote: > Hello, > > This is the case : > > mosefs 3.0.81, Ubuntu 14.04 as master and chunks, freebsd 10.2 as client: > > > folder "project" > :# du -sh project > 191G project > :# > > Ok, so we move to mosefs: > > > :# mv -r project/ /mnt/moosefs/project > :# > > after a while > > :# cd /mnt/moose/ > :# du -sh project > 509G project/ > > ?!?!?! for God's sake - why ???? > > :# mfsgetgoal * > projects : 2 > :# > ..... > Any ideas ? > > > > > -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. This email is not intended to, nor should it be taken to, constitute advice. The information provided is correct to our knowledge & belief and must not be used as a substitute for obtaining tax, regulatory, investment, legal or any other appropriate advice. "Transact" is operated by Integrated Financial Arrangements Ltd. 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. (Registered office: as above; Registered in England and Wales under number: 3727592). Authorised and regulated by the Financial Conduct Authority (entered on the Financial Services Register; no. 190856). |
|
From: Aleksander W. <ale...@mo...> - 2016-08-31 08:28:39
|
Hi, I have one question. How many files you have inside this folder and what is the average file size in original "project" folder? Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 08/31/2016 09:35 AM, Paweł Kowalski wrote: > Hello, > > This is the case : > > mosefs 3.0.81, Ubuntu 14.04 as master and chunks, freebsd 10.2 as client: > > > folder "project" > :# du -sh project > 191G project > :# > > Ok, so we move to mosefs: > > > :# mv -r project/ /mnt/moosefs/project > :# > > after a while > > :# cd /mnt/moose/ > :# du -sh project > 509G project/ > > ?!?!?! for God's sake - why ???? > > :# mfsgetgoal * > projects : 2 > :# > ..... > Any ideas ? > > > > > |
|
From: Paweł K. <ma...@gm...> - 2016-08-31 07:51:21
|
Hello, This is the case : mosefs 3.0.81, Ubuntu 14.04 as master and chunks, freebsd 10.2 as client: folder "project" :# du -sh project 191G project :# Ok, so we move to mosefs: :# mv -r project/ /mnt/moosefs/project :# after a while :# cd /mnt/moose/ :# du -sh project 509G project/ ?!?!?! for God's sake - why ???? :# mfsgetgoal * projects : 2 :# ..... Any ideas ? -- Paweł "Argail" Kowalski |
|
From: Paweł K. <ma...@gm...> - 2016-08-31 07:22:24
|
Hello, This is the case : mosefs 3.0.81 folder "project" :# du -sh project 191G project :# Ok, so we move to mosefs: :# mv -r project /mnt/moosefs/project :# after a while :# cd /mnt/moose/ :# du -sh project 509G project/ ?!?!?! for God's sake - why ???? :# mfsgetgoal * projects : 2 :# ..... -- Paweł "Argail" Kowalski |
|
From: Aleksander W. <ale...@mo...> - 2016-08-24 13:11:13
|
Hi, Thank you for all this information. I would like to add that all clients and chunkservers always communicate only with LEADER MASTER. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 08/24/2016 02:48 PM, Wilson, Steven M wrote: > > Hi, > > > Thanks for your response. All our MooseFS masters are running on > physical hardware (not a VM). The "high packet travel" message is > primarily seen on systems located in other buildings and on different > networks (network traffic must go through two routers besides > switches). The master servers don't approach 100% CPU utilization so > I think the problem must be a network-related issue. And I've not > seen any network interface errors. I will take a look to see if > there's anything we can do to improve our network performance. > > > Regarding the "time desync" message, I do have NTP synchronization in > use on all our systems using local NTP servers here on campus. It > looks like most of the systems reporting this message are also located > in other buildings. > > > I do have one suggestion. It would be helpful in our environment > (many different MooseFS master servers) to include in the log message > which master server is having an issue. For example, an IP address > could be added in parentheses after "master" in the log message: > > mfsmount[9898]: time desync between client and master > *(ip:10.163.216.36)* is higher than a second - it might lead to > strange atime/mtime behaviour - consider time synchronization in your > moosefs cluster > > > Thanks! > > > Steve > > > ------------------------------------------------------------------------ > *From:* Aleksander Wieliczko <ale...@mo...> > *Sent:* Tuesday, August 23, 2016 3:45 AM > *To:* Wilson, Steven M; MooseFS-Users > *Subject:* Re: [MooseFS-Users] high packet travel time > > Hi, > > According to your system log, we can notice two different problems: > > 1.) First problem is "high packet travel". > > I would like to inform you that since version 3.0.x MooseFS has new > time calculation method. > Master is able to calculate "real" packet time travel between MooseFS > Master and clients. > In a glance. Echo packet is send through TCP and goes to master > queue. So time of operation is a sum of time, that Master spends on > ECHO reply and packet travel time. > Time difference larger than 10ms can influence on all operations > performance. > > Information about "high packet travel time" can mean, that: > - Network traffic is huge, > - Router is not able to handle large number of packets traffic, > - Master is busy - CPU utilisation is close to 100%, > - Some interfaces have TX/RX errors. > > If you notice this entry in your system log rarely you can ignore it, > but if you see it often, consider to do some investigation. > Also please check if you network configuration is error-free. > Always good idea is do perform some simple ping test to see if your > latency is really small. > > By the way. Your MooseFS master is hardware or virtual machine? > > > 2.) Second problem i "time desync". > > Information about time de-synchronization between client and master > means that local data is different on master and client. > So please check if you have enabled some ntp time synchronization on > all MooseFS components. > > I'm looking forward to hearing from you. > > Best regards, > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <moosefs.com> |
|
From: Aleksander W. <ale...@mo...> - 2016-08-24 13:10:52
|
Hi, OK. Now all is clear for me. So I will talk to our developers and return to this topic tomorrow. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 08/24/2016 03:02 PM, Wilson, Steven M wrote: > > Hi Aleksander, > > > I wasn't very clear in my message. We aren't using a "pro" > installation with a leader master and follower masters. I meant that > we have multiple MooseFS data clusters, each with their own > chunkservers, metaloggers, and master server. A typical client in our > environment will have MooseFS file systems mounted from three or four > different MooseFS master servers at the same time. > > > Best regards, > Steve > > > ------------------------------------------------------------------------ > *From:* awi...@ge... <awi...@ge...> on behalf of > Aleksander Wieliczko <ale...@mo...> > *Sent:* Wednesday, August 24, 2016 8:55 AM > *To:* Wilson, Steven M > *Cc:* MooseFS-Users > *Subject:* Re: [MooseFS-Users] high packet travel time > > > Hi, > > Thank you for all this information. > > > I would like to add that all clients and chunkservers always > communicate only with LEADER MASTER. > > > Best regards > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <moosefs.com> > > On 08/24/2016 02:48 PM, Wilson, Steven M wrote: >> >> Hi, >> >> >> Thanks for your response. All our MooseFS masters are running on >> physical hardware (not a VM). The "high packet travel" message is >> primarily seen on systems located in other buildings and on different >> networks (network traffic must go through two routers besides >> switches). The master servers don't approach 100% CPU utilization so >> I think the problem must be a network-related issue. And I've not >> seen any network interface errors. I will take a look to see if >> there's anything we can do to improve our network performance. >> >> >> Regarding the "time desync" message, I do have NTP synchronization in >> use on all our systems using local NTP servers here on campus. It >> looks like most of the systems reporting this message are also >> located in other buildings. >> >> >> I do have one suggestion. It would be helpful in our environment >> (many different MooseFS master servers) to include in the log message >> which master server is having an issue. For example, an IP address >> could be added in parentheses after "master" in the log message: >> >> mfsmount[9898]: time desync between client and master >> *(ip:10.163.216.36)* is higher than a second - it might lead to >> strange atime/mtime behaviour - consider time synchronization in your >> moosefs cluster >> >> >> Thanks! >> >> >> Steve >> >> >> ------------------------------------------------------------------------ >> *From:* Aleksander Wieliczko <ale...@mo...> >> *Sent:* Tuesday, August 23, 2016 3:45 AM >> *To:* Wilson, Steven M; MooseFS-Users >> *Subject:* Re: [MooseFS-Users] high packet travel time >> >> Hi, >> >> According to your system log, we can notice two different problems: >> >> 1.) First problem is "high packet travel". >> >> I would like to inform you that since version 3.0.x MooseFS has new >> time calculation method. >> Master is able to calculate "real" packet time travel between MooseFS >> Master and clients. >> In a glance. Echo packet is send through TCP and goes to master >> queue. So time of operation is a sum of time, that Master spends on >> ECHO reply and packet travel time. >> Time difference larger than 10ms can influence on all operations >> performance. >> >> Information about "high packet travel time" can mean, that: >> - Network traffic is huge, >> - Router is not able to handle large number of packets traffic, >> - Master is busy - CPU utilisation is close to 100%, >> - Some interfaces have TX/RX errors. >> >> If you notice this entry in your system log rarely you can ignore it, >> but if you see it often, consider to do some investigation. >> Also please check if you network configuration is error-free. >> Always good idea is do perform some simple ping test to see if your >> latency is really small. >> >> By the way. Your MooseFS master is hardware or virtual machine? >> >> >> 2.) Second problem i "time desync". >> >> Information about time de-synchronization between client and master >> means that local data is different on master and client. >> So please check if you have enabled some ntp time synchronization on >> all MooseFS components. >> >> I'm looking forward to hearing from you. >> >> Best regards, >> Aleksander Wieliczko >> Technical Support Engineer >> MooseFS.com <moosefs.com> > |
|
From: Wilson, S. M <st...@pu...> - 2016-08-24 13:03:10
|
Hi Aleksander, I wasn't very clear in my message. We aren't using a "pro" installation with a leader master and follower masters. I meant that we have multiple MooseFS data clusters, each with their own chunkservers, metaloggers, and master server. A typical client in our environment will have MooseFS file systems mounted from three or four different MooseFS master servers at the same time. Best regards, Steve ________________________________ From: awi...@ge... <awi...@ge...> on behalf of Aleksander Wieliczko <ale...@mo...> Sent: Wednesday, August 24, 2016 8:55 AM To: Wilson, Steven M Cc: MooseFS-Users Subject: Re: [MooseFS-Users] high packet travel time Hi, Thank you for all this information. I would like to add that all clients and chunkservers always communicate only with LEADER MASTER. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com<moosefs.com> On 08/24/2016 02:48 PM, Wilson, Steven M wrote: ?Hi, Thanks for your response. All our MooseFS masters are running on physical hardware (not a VM). The "high packet travel" message is primarily seen on systems located in other buildings and on different networks (network traffic must go through two routers besides switches). The master servers don't approach 100% CPU utilization so I think the problem must be a network-related issue. And I've not seen any network interface errors. I will take a look to see if there's anything we can do to improve our network performance. Regarding the "time desync" message, I do have NTP synchronization in use on all our systems using local NTP servers here on campus. It looks like most of the systems reporting this message are also located in other buildings. I do have one suggestion. It would be helpful in our environment (many different MooseFS master servers) to include in the log message which master server is having an issue. For example, an IP address could be added in parentheses after "master" in the log message: mfsmount[9898]: time desync between client and master (ip:10.163.216.36) is higher than a second - it might lead to strange atime/mtime behaviour - consider time synchronization in your moosefs cluster Thanks! Steve ________________________________ From: Aleksander Wieliczko <ale...@mo...><mailto:ale...@mo...> Sent: Tuesday, August 23, 2016 3:45 AM To: Wilson, Steven M; MooseFS-Users Subject: Re: [MooseFS-Users] high packet travel time Hi, According to your system log, we can notice two different problems: 1.) First problem is "high packet travel". I would like to inform you that since version 3.0.x MooseFS has new time calculation method. Master is able to calculate "real" packet time travel between MooseFS Master and clients. In a glance. Echo packet is send through TCP and goes to master queue. So time of operation is a sum of time, that Master spends on ECHO reply and packet travel time. Time difference larger than 10ms can influence on all operations performance. Information about "high packet travel time" can mean, that: - Network traffic is huge, - Router is not able to handle large number of packets traffic, - Master is busy - CPU utilisation is close to 100%, - Some interfaces have TX/RX errors. If you notice this entry in your system log rarely you can ignore it, but if you see it often, consider to do some investigation. Also please check if you network configuration is error-free. Always good idea is do perform some simple ping test to see if your latency is really small. By the way. Your MooseFS master is hardware or virtual machine? 2.) Second problem i "time desync". Information about time de-synchronization between client and master means that local data is different on master and client. So please check if you have enabled some ntp time synchronization on all MooseFS components. I'm looking forward to hearing from you. Best regards, Aleksander Wieliczko Technical Support Engineer MooseFS.com<moosefs.com> |
|
From: Wilson, S. M <st...@pu...> - 2016-08-24 12:48:38
|
?Hi,
Thanks for your response. All our MooseFS masters are running on physical hardware (not a VM). The "high packet travel" message is primarily seen on systems located in other buildings and on different networks (network traffic must go through two routers besides switches). The master servers don't approach 100% CPU utilization so I think the problem must be a network-related issue. And I've not seen any network interface errors. I will take a look to see if there's anything we can do to improve our network performance.
Regarding the "time desync" message, I do have NTP synchronization in use on all our systems using local NTP servers here on campus. It looks like most of the systems reporting this message are also located in other buildings.
I do have one suggestion. It would be helpful in our environment (many different MooseFS master servers) to include in the log message which master server is having an issue. For example, an IP address could be added in parentheses after "master" in the log message:
mfsmount[9898]: time desync between client and master (ip:10.163.216.36) is higher than a second - it might lead to strange atime/mtime behaviour - consider time synchronization in your moosefs cluster
Thanks!
Steve
________________________________
From: Aleksander Wieliczko <ale...@mo...>
Sent: Tuesday, August 23, 2016 3:45 AM
To: Wilson, Steven M; MooseFS-Users
Subject: Re: [MooseFS-Users] high packet travel time
Hi,
According to your system log, we can notice two different problems:
1.) First problem is "high packet travel".
I would like to inform you that since version 3.0.x MooseFS has new time calculation method.
Master is able to calculate "real" packet time travel between MooseFS Master and clients.
In a glance. Echo packet is send through TCP and goes to master queue. So time of operation is a sum of time, that Master spends on ECHO reply and packet travel time.
Time difference larger than 10ms can influence on all operations performance.
Information about "high packet travel time" can mean, that:
- Network traffic is huge,
- Router is not able to handle large number of packets traffic,
- Master is busy - CPU utilisation is close to 100%,
- Some interfaces have TX/RX errors.
If you notice this entry in your system log rarely you can ignore it, but if you see it often, consider to do some investigation.
Also please check if you network configuration is error-free.
Always good idea is do perform some simple ping test to see if your latency is really small.
By the way. Your MooseFS master is hardware or virtual machine?
2.) Second problem i "time desync".
Information about time de-synchronization between client and master means that local data is different on master and client.
So please check if you have enabled some ntp time synchronization on all MooseFS components.
I'm looking forward to hearing from you.
Best regards,
Aleksander Wieliczko
Technical Support Engineer
MooseFS.com<moosefs.com>
|
|
From: Aleksander W. <ale...@mo...> - 2016-08-23 07:45:32
|
Hi, According to your system log, we can notice two different problems: 1.) First problem is "high packet travel". I would like to inform you that since version 3.0.x MooseFS has new time calculation method. Master is able to calculate "real" packet time travel between MooseFS Master and clients. In a glance. Echo packet is send through TCP and goes to master queue. So time of operation is a sum of time, that Master spends on ECHO reply and packet travel time. Time difference larger than 10ms can influence on all operations performance. Information about "high packet travel time" can mean, that: - Network traffic is huge, - Router is not able to handle large number of packets traffic, - Master is busy - CPU utilisation is close to 100%, - Some interfaces have TX/RX errors. If you notice this entry in your system log rarely you can ignore it, but if you see it often, consider to do some investigation. Also please check if you network configuration is error-free. Always good idea is do perform some simple ping test to see if your latency is really small. By the way. Your MooseFS master is hardware or virtual machine? 2.) Second problem i "time desync". Information about time de-synchronization between client and master means that local data is different on master and client. So please check if you have enabled some ntp time synchronization on all MooseFS components. I'm looking forward to hearing from you. Best regards, Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> |
|
From: Wilson, S. M <st...@pu...> - 2016-08-18 14:10:12
|
Hi, Ever since upgrading our MooseFS installations to v. 3.0.x, I've been seeing numerous messages like the following in the logs: ??mfsmount[22071]: high packet travel time between client and master (0.133616s) - ignoring in time sync mfsmount[2655]: time desync between client and master is higher than a second - it might lead to strange atime/mtime behaviour - consider time synchronization in your moosefs cluster? ? I think this just indicates that I'm using a congested network and some packets take longer than expected between the client and the master. Is our network uncommonly busy? Or is this fairly normal to see? All our equipment use 1GbE networking with a few on a 10GbE network. Thanks, Steve |
|
From: Alex M. <al...@is...> - 2016-08-15 06:45:20
|
Aleksander, Thanks a lot. Regards, Alex. On Sun, Aug 14, 2016 at 7:37 PM, Aleksander Wieliczko < ale...@mo...> wrote: > Hi Alex. > > At this moment we don't have native systemd support in MooseFS for Debian > / Ubuntu operating systems, but packages for Ubuntu 14.04 work great on > Ubuntu 16.04. > > Best regards > Aleksander Wieliczko > MooseFS Support Engineer > > > On 14.08.2016 14:19, Alex Milzon wrote: > > Hello Piotr, > I'm planning to upgrade my servers to ubuntu 16.04LTS. > Is it possible to find moosefs-client for this OS? > > > Regards, > Alex. > > On Mon, Jul 4, 2016 at 12:41 PM, Piotr Robert Konopelko < > pio...@mo...> wrote: > >> Hi Alex, >> >> just use the following entry in /etc/apt/sources.list.d/moosefs.list: >> >> deb http://ppa.moosefs.com/2.0.81/apt/ubuntu/precise precise main >> >> >> Best regards, >> Peter >> >> -- >> [image: MooseFS] <https://moosefs.com> >> >> Piotr Robert Konopelko >> MooseFS Technical Support Engineer >> e-mail : pio...@mo... >> www : https://moosefs.com >> >> [image: Twitter] <https://twitter.com/MooseFS> [image: Facebook] >> <https://www.facebook.com/moosefs> [image: LinkedIn] >> <https://www.linkedin.com/company/moosefs> [image: GitHub] >> <https://github.com/moosefs> >> >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they are >> addressed. If you have received it by mistake, please let us know by e-mail >> reply and delete it from your system; you may not copy this message or >> disclose its contents to anyone. Finally, the recipient should check this >> email and any attachments for the presence of viruses. Core Technology >> accepts no liability for any damage caused by any virus transmitted by this >> email. >> >> On 04 Jul 2016, at 9:03 AM, Alex Milzon <al...@is...> wrote: >> >> Hello, >> I'm looking to download moosefs-client version 2.0.81-1 for Ubuntu 12.04 >> Precise, amd64. >> Can you please help me with it? >> >> Thanks in advance, >> Alex. >> ------------------------------------------------------------ >> ------------------ >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries >> present their vision of the future. This family event has something for >> everyone, including kids. Get more information and register today. >> http://sdm.link/attshape_________________________________________ >> moosefs-users mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moosefs-users >> >> >> > > > ------------------------------------------------------------------------------ > 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. http://sdm.link/zohodev2dev > > > > _________________________________________ > moosefs-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > |
|
From: Aleksander W. <ale...@mo...> - 2016-08-14 16:38:00
|
Hi Alex. At this moment we don't have native systemd support in MooseFS for Debian / Ubuntu operating systems, but packages for Ubuntu 14.04 work great on Ubuntu 16.04. Best regards Aleksander Wieliczko MooseFS Support Engineer On 14.08.2016 14:19, Alex Milzon wrote: > Hello Piotr, > I'm planning to upgrade my servers to ubuntu 16.04LTS. > Is it possible to find moosefs-client for this OS? > > > Regards, > Alex. > > On Mon, Jul 4, 2016 at 12:41 PM, Piotr Robert Konopelko > <pio...@mo... <mailto:pio...@mo...>> wrote: > > Hi Alex, > > just use the following entry in /etc/apt/sources.list.d/moosefs.list: > > deb http://ppa.moosefs.com/2.0.81/apt/ubuntu/precise > <http://ppa.moosefs.com/2.0.81/apt/ubuntu/precise> precise main > > > Best regards, > Peter > > -- > > MooseFS <https://moosefs.com> > > Piotr Robert Konopelko > MooseFS Technical Support Engineer > e-mail: pio...@mo... > <mailto:pio...@mo...> > www: https://moosefs.com > > Twitter <https://twitter.com/MooseFS> Facebook > <https://www.facebook.com/moosefs> LinkedIn > <https://www.linkedin.com/company/moosefs> GitHub > <https://github.com/moosefs> > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom > they are addressed. If you have received it by mistake, please let > us know by e-mail reply and delete it from your system; you may > not copy this message or disclose its contents to anyone. Finally, > the recipient should check this email and any attachments for the > presence of viruses. Core Technology accepts no liability for any > damage caused by any virus transmitted by this email. > > >> On 04 Jul 2016, at 9:03 AM, Alex Milzon <al...@is... >> <mailto:al...@is...>> wrote: >> >> Hello, >> I'm looking to download moosefs-client version 2.0.81-1 for >> Ubuntu 12.04 Precise, amd64. >> Can you please help me with it? >> >> Thanks in advance, >> Alex. >> ------------------------------------------------------------------------------ >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park >> in San >> Francisco, CA to explore cutting-edge tech and listen to tech >> luminaries >> present their vision of the future. This family event has >> something for >> everyone, including kids. Get more information and register today. >> http://sdm.link/attshape_________________________________________ >> <http://sdm.link/attshape_________________________________________> >> 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> > > > > > ------------------------------------------------------------------------------ > 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. http://sdm.link/zohodev2dev > > > _________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Alex M. <al...@is...> - 2016-08-14 12:42:01
|
Hello Piotr, I'm planning to upgrade my servers to ubuntu 16.04LTS. Is it possible to find moosefs-client for this OS? Regards, Alex. On Mon, Jul 4, 2016 at 12:41 PM, Piotr Robert Konopelko < pio...@mo...> wrote: > Hi Alex, > > just use the following entry in /etc/apt/sources.list.d/moosefs.list: > > deb http://ppa.moosefs.com/2.0.81/apt/ubuntu/precise precise main > > > Best regards, > Peter > > -- > [image: MooseFS] <https://moosefs.com> > > Piotr Robert Konopelko > MooseFS Technical Support Engineer > e-mail : pio...@mo... > www : https://moosefs.com > > [image: Twitter] <https://twitter.com/MooseFS> [image: Facebook] > <https://www.facebook.com/moosefs> [image: LinkedIn] > <https://www.linkedin.com/company/moosefs> [image: GitHub] > <https://github.com/moosefs> > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received it by mistake, please let us know by e-mail reply and > delete it from your system; you may not copy this message or disclose its > contents to anyone. Finally, the recipient should check this email and any > attachments for the presence of viruses. Core Technology accepts no > liability for any damage caused by any virus transmitted by this email. > > On 04 Jul 2016, at 9:03 AM, Alex Milzon <al...@is...> wrote: > > Hello, > I'm looking to download moosefs-client version 2.0.81-1 for Ubuntu 12.04 > Precise, amd64. > Can you please help me with it? > > Thanks in advance, > Alex. > ------------------------------------------------------------ > ------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape_________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > |
84 messages has been excluded from this view by a project administrator.
