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: Ólafur Ó. <osv...@ne...> - 2011-06-27 15:52:32
|
Hi, Our system had just over 4.5 million chunks untill one week ago when a good deal of the data was deleted (on purpose). Today the trash time expired and it seems that our master is deleting all the unused chunks which is quite normal except each server of 10 is doing up to 5.5k chunk deletions pr. minute and all systems accessing the MFS partitions are very slow and that started at the same time as the chunk deletions. Is there any way to tune MFS so that chunk deletions don't have such an impact on the system, can we somehow control how many chunks are deleted at once in max rate pr. minute or maybe have it somehow linked to chunkserver/master load? The network links are not saturated and none of the servers seem to be loaded at all? The disk io on the master even went down when this started, as did the CPU usage of the server, but the memory usage has gone up about 30% Could it be that the master process is not handling all this at once? /Oli -- Ólafur Osvaldsson System Administrator Nethonnun ehf. e-mail: osv...@ne... phone: +354 517 3400 |
|
From: <leo...@ar...> - 2011-06-26 21:52:16
|
Oh, I've found it in the howto: http://www.moosefs.org/moosefs-faq.html#goal-0 It seems, that I have to wait for week (isn't there any way to force this process?... )... or reinitialise chunkservers manually, one by one, deleting all the data... On Mon, 27 Jun 2011 00:56:33 +0400, wrote: Greetings! While testing the cluster today I've emulated metadata loss on the server, so a number of chunks are not associated with any file and appear to be of goal 0... The question is: will they be deleted automatically?... |
|
From: WK <wk...@bn...> - 2011-06-26 21:28:09
|
One one of our MFS clusters has four clients mounted. Three of them running RHEL5/Cent5 never have issues. The fourth locks up at least once a week, with the below /var/log/messages (note the mount errors just go on forever until we reboot). It starts with khugepaged. Googling the issue indicates that many people are seeing this with other fuse projects all with recent kernels. In particular the ZFS project has a number of threads. Here is just one thread: http://zfs-fuse.net/issues/123 In that thread, aside from downgrading the distro there is a recommenation of limiting the memory used to 1GB or less using "zfs-fuse --stack-size=1024 -m 1024 --no-kstat-mount --disable-block-cache --disable-page-cache -v 1 --zfs-prefetch-disable". Is there a MFSmount equivalent for limiting memory or any suggestions/feedback regarding this issue. Sincerely, WK LOG FILE snippet Jun 26 13:41:25 ariel kernel: INFO: task khugepaged:52 blocked for more than 120 seconds. Jun 26 13:41:25 ariel kernel: "echo 0> /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jun 26 13:41:25 ariel kernel: khugepaged D ffff88012fc23080 0 52 2 0x00000000 Jun 26 13:41:25 ariel kernel: ffff88012af9f900 0000000000000046 0000000000000000 ffffffff8104b9c8 Jun 26 13:41:25 ariel kernel: 0000000002dae000 ffffea000027a050 000000000000000e 0000000113d439da Jun 26 13:41:25 ariel kernel: ffff88012afa3ad8 ffff88012af9ffd8 0000000000010518 ffff88012afa3ad8 Jun 26 13:41:25 ariel kernel: Call Trace: Jun 26 13:41:25 ariel kernel: [<ffffffff8104b9c8>] ? flush_tlb_others_ipi+0x128/0x130 Jun 26 13:41:25 ariel kernel: [<ffffffff8110c330>] ? sync_page+0x0/0x50 Jun 26 13:41:25 ariel kernel: [<ffffffff814c9a53>] io_schedule+0x73/0xc0 Jun 26 13:41:25 ariel kernel: [<ffffffff8110c36d>] sync_page+0x3d/0x50 Jun 26 13:41:25 ariel kernel: [<ffffffff814ca17a>] __wait_on_bit_lock+0x5a/0xc0 Jun 26 13:41:25 ariel kernel: [<ffffffff8110c307>] __lock_page+0x67/0x70 Jun 26 13:41:25 ariel kernel: [<ffffffff81091ee0>] ? wake_bit_function+0x0/0x50 Jun 26 13:41:25 ariel kernel: [<ffffffff81122781>] ? lru_cache_add_lru+0x21/0x40 Jun 26 13:41:25 ariel kernel: [<ffffffff8115bf10>] lock_page+0x30/0x40 Jun 26 13:41:25 ariel kernel: [<ffffffff8115c58d>] migrate_pages+0x59d/0x5d0 Jun 26 13:41:25 ariel kernel: [<ffffffff81152b20>] ? compaction_alloc+0x0/0x370 Jun 26 13:41:25 ariel kernel: [<ffffffff811525cc>] compact_zone+0x4cc/0x600 Jun 26 13:41:25 ariel kernel: [<ffffffff8111cffc>] ? get_page_from_freelist+0x15c/0x820 Jun 26 13:41:25 ariel kernel: [<ffffffff8115297e>] compact_zone_order+0x7e/0xb0 Jun 26 13:41:25 ariel kernel: [<ffffffff81152ab9>] try_to_compact_pages+0x109/0x170 Jun 26 13:41:25 ariel kernel: [<ffffffff8111e99d>] __alloc_pages_nodemask+0x5ed/0x850 Jun 26 13:41:25 ariel kernel: [<ffffffff81150db3>] alloc_pages_vma+0x93/0x150 Jun 26 13:41:25 ariel kernel: [<ffffffff81165c4b>] khugepaged+0xa9b/0x1210 Jun 26 13:41:25 ariel kernel: [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40 Jun 26 13:41:25 ariel kernel: [<ffffffff811651b0>] ? khugepaged+0x0/0x1210 Jun 26 13:41:25 ariel kernel: [<ffffffff81091b36>] kthread+0x96/0xa0 Jun 26 13:41:25 ariel kernel: [<ffffffff810141ca>] child_rip+0xa/0x20 Jun 26 13:41:25 ariel kernel: [<ffffffff81091aa0>] ? kthread+0x0/0xa0 Jun 26 13:41:25 ariel kernel: [<ffffffff810141c0>] ? child_rip+0x0/0x20 Jun 26 13:41:25 ariel kernel: INFO: task mfsmount:7808 blocked for more than 120 seconds. Jun 26 13:41:25 ariel kernel: "echo 0> /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jun 26 13:41:25 ariel kernel: mfsmount D ffff88012fc23280 0 7808 1 0x00000000 Jun 26 13:41:25 ariel kernel: ffff8800730e1b70 0000000000000086 0000000000000000 0000000000000000 Jun 26 13:41:25 ariel kernel: ffff8800282912c0 0000000000000400 0000000000001000 0000000113d44058 Jun 26 13:41:25 ariel kernel: ffff8801121f45f8 ffff8800730e1fd8 0000000000010518 ffff8801121f45f8 Jun 26 13:41:25 ariel kernel: Call Trace: Jun 26 13:41:25 ariel kernel: [<ffffffff814cb6e5>] rwsem_down_failed_common+0x95/0x1d0 Jun 26 13:41:25 ariel kernel: [<ffffffff81059e02>] ? finish_task_switch+0x42/0xd0 Jun 26 13:41:25 ariel kernel: [<ffffffff814cb876>] rwsem_down_read_failed+0x26/0x30 Jun 26 13:41:25 ariel kernel: [<ffffffff81264db4>] call_rwsem_down_read_failed+0x14/0x30 Jun 26 13:41:25 ariel kernel: [<ffffffff814cad74>] ? down_read+0x24/0x30 Jun 26 13:41:25 ariel kernel: [<ffffffffa0370419>] fuse_copy_fill+0x99/0x1f0 [fuse] Jun 26 13:41:25 ariel kernel: [<ffffffffa03705b1>] fuse_copy_one+0x41/0x70 [fuse] Jun 26 13:41:25 ariel kernel: [<ffffffffa03714c4>] fuse_dev_read+0x224/0x310 [fuse] Jun 26 13:41:25 ariel kernel: [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40 Jun 26 13:41:25 ariel kernel: [<ffffffff8116d19a>] do_sync_read+0xfa/0x140 Jun 26 13:41:25 ariel kernel: [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40 Jun 26 13:41:25 ariel kernel: [<ffffffff81401e77>] ? release_sock+0xb7/0xd0 Jun 26 13:41:25 ariel kernel: [<ffffffff811fff16>] ? security_file_permission+0x16/0x20 Jun 26 13:41:25 ariel kernel: [<ffffffff8116dbc5>] vfs_read+0xb5/0x1a0 Jun 26 13:41:25 ariel kernel: [<ffffffff8116dd01>] sys_read+0x51/0x90 Jun 26 13:41:25 ariel kernel: [<ffffffff81013172>] system_call_fastpath+0x16/0x1b Jun 26 13:41:25 ariel kernel: INFO: task mfsmount:3885 blocked for more than 120 seconds. Jun 26 13:41:25 ariel kernel: "echo 0> /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jun 26 13:41:25 ariel kernel: mfsmount D ffff88012fc23280 0 3885 1 0x00000000 Jun 26 13:41:25 ariel kernel: ffff880063e1bb70 0000000000000086 0000000000000000 ffff880063e1baf8 Jun 26 13:41:25 ariel kernel: ffff880028316980 ffff880063e1bb18 ffffffff8105c846 0000000113d44249 Jun 26 13:41:25 ariel kernel: ffff880044ea6678 ffff880063e1bfd8 0000000000010518 ffff880044ea6678 Jun 26 13:41:25 ariel kernel: Call Trace: Jun 26 13:41:25 ariel kernel: [<ffffffff8105c846>] ? update_curr+0xe6/0x1e0 Jun 26 13:41:25 ariel kernel: [<ffffffff81061c61>] ? dequeue_entity+0x1a1/0x1e0 Jun 26 13:41:25 ariel kernel: [<ffffffff814cb6e5>] rwsem_down_failed_common+0x95/0x1d0 Jun 26 13:41:25 ariel kernel: [<ffffffff81059e02>] ? finish_task_switch+0x42/0xd0 Jun 26 13:41:25 ariel kernel: [<ffffffff814cb876>] rwsem_down_read_failed+0x26/0x30 Jun 26 13:41:25 ariel kernel: [<ffffffff81264db4>] call_rwsem_down_read_failed+0x14/0x30 Jun 26 13:41:25 ariel kernel: [<ffffffff814cad74>] ? down_read+0x24/0x30 Jun 26 13:41:25 ariel kernel: [<ffffffffa0370419>] fuse_copy_fill+0x99/0x1f0 [fuse] Jun 26 13:41:25 ariel kernel: [<ffffffffa03705b1>] fuse_copy_one+0x41/0x70 [fuse] Jun 26 13:41:25 ariel kernel: [<ffffffffa03714c4>] fuse_dev_read+0x224/0x310 [fuse] Jun 26 13:41:25 ariel kernel: [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40 Jun 26 13:41:25 ariel kernel: [<ffffffff8116d19a>] do_sync_read+0xfa/0x140 Jun 26 13:41:25 ariel kernel: [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40 Jun 26 13:41:25 ariel kernel: [<ffffffff81401e77>] ? release_sock+0xb7/0xd0 Jun 26 13:41:25 ariel kernel: [<ffffffff811fff16>] ? security_file_permission+0x16/0x20 Jun 26 13:41:25 ariel kernel: [<ffffffff8116dbc5>] vfs_read+0xb5/0x1a0 Jun 26 13:41:25 ariel kernel: [<ffffffff8116dd01>] sys_read+0x51/0x90 Jun 26 13:41:25 ariel kernel: [<ffffffff81013172>] system_call_fastpath+0x16/0x1b Jun 26 13:41:25 ariel kernel: INFO: task mfsmount:21898 blocked for more than 120 seconds. Jun 26 13:41:25 ariel kernel: "echo 0> /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jun 26 13:41:25 ariel kernel: mfsmount D ffff88012fc23280 0 21898 1 0x00000000 Jun 26 13:41:25 ariel kernel: ffff8800cdfe7b70 0000000000000086 0000000000000000 0000000000000000 Jun 26 13:41:25 ariel kernel: ffff8800282912c0 0000000000000400 0000000000001000 0000000113d439a9 Jun 26 13:41:25 ariel kernel: ffff8801298d45f8 ffff8800cdfe7fd8 0000000000010518 ffff8801298d45f8 Jun 26 13:41:25 ariel kernel: Call Trace: Jun 26 13:41:25 ariel kernel: [<ffffffff814cb6e5>] rwsem_down_failed_common+0x95/0x1d0 Jun 26 13:41:25 ariel kernel: [<ffffffff81059e02>] ? finish_task_switch+0x42/0xd0 Jun 26 13:41:25 ariel kernel: [<ffffffff814cb876>] rwsem_down_read_failed+0x26/0x30 Jun 26 13:41:25 ariel kernel: [<ffffffff81264db4>] call_rwsem_down_read_failed+0x14/0x30 Jun 26 13:41:25 ariel kernel: [<ffffffff814cad74>] ? down_read+0x24/0x30 Jun 26 13:41:25 ariel kernel: [<ffffffffa0370419>] fuse_copy_fill+0x99/0x1f0 [fuse] Jun 26 13:41:25 ariel kernel: [<ffffffffa03705b1>] fuse_copy_one+0x41/0x70 [fuse] Jun 26 13:41:25 ariel kernel: [<ffffffffa03714c4>] fuse_dev_read+0x224/0x310 [fuse] Jun 26 13:41:25 ariel kernel: [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40 Jun 26 13:41:25 ariel kernel: [<ffffffff8116d19a>] do_sync_read+0xfa/0x140 Jun 26 13:41:25 ariel kernel: [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40 Jun 26 13:41:25 ariel kernel: [<ffffffff8118bf70>] ? mntput_no_expire+0x30/0x110 Jun 26 13:41:25 ariel kernel: [<ffffffff811fff16>] ? security_file_permission+0x16/0x20 Jun 26 13:41:25 ariel kernel: [<ffffffff8116dbc5>] vfs_read+0xb5/0x1a0 Jun 26 13:41:25 ariel kernel: [<ffffffff8116dd01>] sys_read+0x51/0x90 Jun 26 13:41:25 ariel kernel: [<ffffffff81013172>] system_call_fastpath+0x16/0x1b and so on. |
|
From: <leo...@ar...> - 2011-06-26 21:21:26
|
Greetings! While testing the cluster today I've emulated metadata loss on the server, so a number of chunks are not associated with any file and appear to be of goal 0... The question is: will they be deleted automatically?... |
|
From: Florent B. <fl...@co...> - 2011-06-23 07:46:10
|
Hi all, I have a problem with an installation of MooseFS. MFS is successfully mounted by a client, all files are readable and writtable, but every command mfs* is not working and returns : register to master: Permission denied For example : test1:~# mfsdirinfo /mfs/Ahng2u/ register to master: Permission denied /mfs/Ahng2u/: can't register to master (.masterinfo) But I confirm that this client is using the files without problem (some KVM machines are stored on it and running !). What can be the problem ? This is the first time I'm having this error. I do not see anything in syslog, but maybe I'm not looking in the right place! -- Florent Bautista ------------------------------------------------------------------------ Ce message et ses éventuelles pièces jointes sont personnels, confidentiels et à l'usage exclusif de leur destinataire. Si vous n'êtes pas la personne à laquelle ce message est destiné, veuillez noter que vous avez reçu ce courriel par erreur et qu'il vous est strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message. This e-mail and any attachments hereto are strictly personal, confidential and intended solely for the addressee. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this message is strictly prohibited. ------------------------------------------------------------------------ 30440 Saint Laurent le Minier France *Compagnie pour des Prestations Internet* Téléphone : +33 (0)467 73 89 48 Télécopie : + 33 (0)9 59 48 06 27 Courriel : Fl...@Co... <mailto:fl...@co...> ------------------------------------------------------------------------ |
|
From: rxknhe <rx...@gm...> - 2011-06-21 11:46:45
|
You mean 'rack-awareness' in a cluster, such as Hadoop. It doesn't have to be on IP based, that is too rigid setup in a large networks. Looks like MooseFS road map has some reference to a feature like 'Location awareness' http://www.moosefs.org/roadmap.html , so I would vote for that as a good feature to add in the future releases as well. On Mon, Jun 20, 2011 at 11:02 PM, Mike <isp...@gm...> wrote: > > What if someone wrote a patch for MooseFS that looked at the IP of the > client, and the IP of the chunk servers that had the chunk the client > wanted, and tried to pick the closest one? > > something like > > client = 10.1.1.1 > chunkserver with copy#1 = 10.1.1.2 > chunkserver with copy#2 = 10.1.1.20 > chunkserver with copy#3 = 10.1.2.2 > > Those 3 chunk servers would be used in that order, since their IPs are > closer to the client's IP (using a formula like a*256^3+b*256^2+c*256+d > to calculate an integer? long int? based on an IP address). > > This way you could have "close" chunk servers respond to most of the > requests from a client, but if no "close" server had the chunk you > wanted, you could go to a "distant" one. > > Drop two IPs on the client's interface, and do some careful numbering, > and you can even set preference on a machine on the same LAN. > > This might make for a really simple way to do "distant" archives that > don't get used for reads unless they are the only source that's > available, and other similar problems. > > writes would be a different problem. > > Thoughts? comments? > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users > |
|
From: Mike <isp...@gm...> - 2011-06-21 03:02:09
|
What if someone wrote a patch for MooseFS that looked at the IP of the client, and the IP of the chunk servers that had the chunk the client wanted, and tried to pick the closest one? something like client = 10.1.1.1 chunkserver with copy#1 = 10.1.1.2 chunkserver with copy#2 = 10.1.1.20 chunkserver with copy#3 = 10.1.2.2 Those 3 chunk servers would be used in that order, since their IPs are closer to the client's IP (using a formula like a*256^3+b*256^2+c*256+d to calculate an integer? long int? based on an IP address). This way you could have "close" chunk servers respond to most of the requests from a client, but if no "close" server had the chunk you wanted, you could go to a "distant" one. Drop two IPs on the client's interface, and do some careful numbering, and you can even set preference on a machine on the same LAN. This might make for a really simple way to do "distant" archives that don't get used for reads unless they are the only source that's available, and other similar problems. writes would be a different problem. Thoughts? comments? |
|
From: Giovanni T. <gt...@li...> - 2011-06-20 12:31:37
|
Hi, I'm trying to make a simple backup script for my MooseFS volume using mfsmakesnapshot. However on my volume there are many symlinks created by the application, and I would like to copy the referenced file and not the symlink. It's possible to implement in mfsmakesnapshot an option like cp -L? Thanks. -- Giovanni Toraldo http://www.libersoft.it/ |
|
From: Alexander A. <akh...@ri...> - 2011-06-17 16:27:54
|
Hi ALL! I have to tell You a bit interesting story. I am testing a ZFS as a backend storage for chunk server. # uname -a FreeBSD mfs-chunk 8.1-RELEASE FreeBSD 8.1-RELEASE On a ZFS formated partition compression is turned on. And now after rebalancing I have the following usage ratio displayed by CGI Monitor: 36 % on all "normal" disks 24 % on ZFS formated disk (24 GiB used of 98 GiB total) On the ZFS-aware chunk server I see: # mount mfs on /moosefs_store (zfs, local, noexec) # df -h mfs 98G 24G 74G 24% /moosefs_store # du -h -A -d 0 /moosefs_store 32G /moosefs_store # zfs get compressratio NAME PROPERTY VALUE SOURCE mfs compressratio 1.36x - So... as we know MooseFS aligns disk usage of chunk servers. Usage of compressed FS shows me that MooseFS aligns disk usage by value calculated as sum of chunk-files (in my example du shows me it) and not bu free or used space reported by OS (df shows me it). I am not sure if it is bad or good. I'v just reported my observation ;--) wbr Alexander |
|
From: Christoph R. <c.r...@sc...> - 2011-06-17 11:31:08
|
Hi @all, I had a problem. After testing the ucarp Failover script all my Files are on goal 0. The chunks where found by the master but the Inode show only one file / directory. This is the output of the "master start" command. ############## working directory: /var/lib/mfs lockfile created and locked initializing mfsmaster modules ... loading sessions ... ok sessions file has been loaded exports file has been loaded loading metadata ... loading objects (files,directories,etc.) ... ok loading names ... ok loading deletion timestamps ... ok checking filesystem consistency ... ok loading chunks data ... ok connecting files and chunks ... ok all inodes: 1 directory inodes: 1 file inodes: 0 chunks: 426 metadata file has been loaded no charts data file - initializing empty charts master <-> metaloggers module: listen on *:9419 master <-> chunkservers module: listen on *:9420 main master server module: listen on *:9421 mfsmaster daemon initialized properly ############## When I connect the mfscgiserv, ~ 800 chunks where found. But all have goal 0 Has someone a solution to get my data back? Best regards, christoph -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 |
|
From: Steve <st...@bo...> - 2011-06-14 14:07:40
|
Thanks. I will take another look and give it a try tonight. -------Original Message------- From: Papp Tamas Date: 14/06/2011 08:37:21 To: Steve Cc: moo...@li... Subject: Re: [Moosefs-users] ubuntu On 06/14/2011 12:44 AM, Steve wrote: > Looking for 11.04 > > You can rebuild the packages by the command 'apt-get source -b <package>' . tamas |
|
From: Laurent W. <lw...@hy...> - 2011-06-14 09:44:26
|
On Mon, 13 Jun 2011 17:20:39 -0700 Howie Chen <ho...@he...> wrote: > Dear MFS users, Hello, > > How come my moosefs cannot replicate data automatically? Where to turn on this option? Either you're joking, or you forgot to set goal >1 (mfssetgoal), or you didn't wait enough once goal has been set ? It can take a couple minutes. Oh, and if you have a single chunkserver, a goal >1 isn't taken care of, because it has absolutely no use. Hope it helps, -- Laurent Wandrebeck HYGEOS, Earth Observation Department / Observation de la Terre Euratechnologies 165 Avenue de Bretagne 59000 Lille, France tel: +33 3 20 08 24 98 http://www.hygeos.com GPG fingerprint/Empreinte GPG: F5CA 37A4 6D03 A90C 7A1D 2A62 54E6 EF2C D17C F64C |
|
From: Christoph R. <c.r...@sc...> - 2011-06-14 08:34:02
|
Am 14.06.2011 02:20, schrieb Howie Chen: > Dear MFS users, > > How come my moosefs cannot replicate data automatically? Where to turn on this option? > > Thank you. > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users Did you set the goal to your files / direcotry? Check with "mfsgetgoal directory/filename" if it is set to 1 you have to do "mfssetgoal 2 directory/filename" <-- change to your needs. More information with "man mfssetgoal" If mfsgetgoal shows a number greater than 1 then there is an error / bug an we need more information ;) Regards, Chris -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 |
|
From: Papp T. <to...@ma...> - 2011-06-14 07:38:29
|
On 06/14/2011 12:44 AM, Steve wrote: > Looking for 11.04 > > You can rebuild the packages by the command 'apt-get source -b <package>' . tamas |
|
From: Howie C. <ho...@he...> - 2011-06-14 02:18:08
|
Dear MFS users, How come my moosefs cannot replicate data automatically? Where to turn on this option? Thank you. |
|
From: Steve <st...@bo...> - 2011-06-13 22:44:40
|
Looking for 11.04 -------Original Message------- From: Papp Tamas Date: 13/06/2011 22:03:00 To: Steve Cc: moo...@li... Subject: Re: [Moosefs-users] ubuntu On 06/13/2011 10:43 PM, Steve wrote: > Any ubuntu server install packages ? There is a ppa for it, try google to find it. tamas |
|
From: Papp T. <to...@ma...> - 2011-06-13 20:54:51
|
On 06/13/2011 10:43 PM, Steve wrote: > Any ubuntu server install packages ? There is a ppa for it, try google to find it. tamas |
|
From: Steve <st...@bo...> - 2011-06-13 20:43:44
|
Any ubuntu server install packages ? |
|
From: rxknhe <rx...@gm...> - 2011-06-13 14:41:21
|
Not on Solaris ZFS, but I am running on ZFS on linux (http://zfsonlinux.org/) on Scientific Linux 6 (One of RHEL derived distribution and very nice like CentOS). So far no issues running ZFS native on Linux side and using those as MooseFS chunk servers. Oracle/Solaris licensing model is getting very strange, and Opensolaris is not actively pursued as before, so looks like ZFS on linux may become a viable production grade option in the near future. On Mon, Jun 13, 2011 at 4:46 AM, R.C. <mil...@gm...> wrote: > Hello to list's members. > > Has anynoe yet tried to run MFS on Oracle Solaris 11 Express? > I'm considering it for its data corruption robustness due to integrated > ZFS. > > Thank you > > Raf > > > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users > |
|
From: Steve <st...@bo...> - 2011-06-11 13:50:33
|
Hi, Spoke to soon about surviving many power failures with no harm! Master: needed mfsmetarestore -a no errors reported. Mount and samba server: ok Chunks 1-3: started ok scanned disks no reported error starting daemons Chunk 4 the OS drive is physically trashed. The first hard drive ive lost in over 20 years. I have a compact flash on order to replace it. Master (with chunk 4 offline) reports errors such as:- Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4921 has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4921_00000002 - invalid copy on (192.168.3.122 - ver:00000001) Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E499C has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E499C_00000002 - invalid copy on (192.168.3.122 - ver:00000001) Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4A17 has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4A17_00000002 - invalid copy on (192.168.3.123 - ver:00000001) Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4A92 has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4A92_00000002 - invalid copy on (192.168.3.123 - ver:00000001) Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4C03 has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4C03_00000002 - invalid copy on (192.168.3.121 - ver:00000001) Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4C7E has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4C7E_00000002 - invalid copy on (192.168.3.121 - ver:00000001) Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4CF9 has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4CF9_00000002 - invalid copy on (192.168.3.121 - ver:00000001) Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4DEF has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4DEF_00000002 - invalid copy on (192.168.3.122 - ver:00000001) Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4E6A has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E4E6A_00000002 - invalid copy on (192.168.3.122 - ver:00000001) Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E5806 has only invalid copies (1) - please repair it manually Jun 11 15:10:41 localhost mfsmaster[4398]: chunk 00000000000E5806_00000002 - invalid copy on (192.168.3.123 - ver:00000001) Jun 11 15:10:43 localhost mfsmaster[4398]: chunk 00000000000E49B3 has only invalid copies (1) - please repair it manually In the meantime I cant really use the system via samba. I can list the root and sub dirs but trying to use a file result in windows going to sleep. Is this because the master is too busy scanning/reporting errors ? Can I adjust this ? Are my errors terminal ? |
|
From: R.C. <mil...@gm...> - 2011-06-10 19:37:10
|
No native plugin for ESX. You have to mount it on a different machine and then share, preferably with iSCSI. If your mfsmaster has very much RAM and a lot of bogomips, it could act as a sharing client too (but many purists would say that I'm quite a fool :-) Raf -- msg. originale -- Oggetto: [Moosefs-users] ESX as MooseFS client Da: Alexander Akhobadze <akh...@ri...> Data: 10/06/2011 07:14 Hi All! Does anybody know if it is possible to mount MooseFS on ESX ? And if YES - how to do this? wbr Alexander Akhobadze ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ moosefs-users mailing list moo...@li... https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Alexander A. <akh...@ri...> - 2011-06-10 05:14:16
|
Hi All! Does anybody know if it is possible to mount MooseFS on ESX ? And if YES - how to do this? wbr Alexander Akhobadze |
|
From: Thomas S H. <tha...@gm...> - 2011-06-09 16:38:23
|
Right :) There are a lot of solutions, and none of them are easy to get right. But all in all I think that the MooseFS team is perfectly capable of figuring this one out, Jakob is crazy smart! On Thu, Jun 9, 2011 at 10:34 AM, Steve <st...@bo...> wrote: > > Ahh I see complex problem. > > > > A few mins googling and seeing what google use - they have 'chubby' > > > > > > > > > > -------Original Message------- > > > > From: Thomas S Hatch > > Date: 09/06/2011 16:16:35 > > To: Steve > > Cc: Florent Bautista; moo...@li... > > Subject: Re: [Moosefs-users] Failover of MFSMaster > > > > Unfortunately no. > > > > > > The problem is that the master holds all of the filesystem metadata, and if > you had multiple master then you would need to guarantee that all masters > have consistent data. > > > > > > This is a classic distributed database problem, and has still not been > solved by projects like MySQL. > > > > > > There are few models out there for distributed master load, but the end > result is almost always lower speed for the client, because more checks > need > to me put in place, or as is the case in a number of other distributed > filesystems, a lot of the load is displaced to the client. > > > > > > I will agree that right now the master is the greatset point of failure and > load issues in MooseFS. This is why I will still lobby for MooseFS to grate > an active replicated master and clients that can query multiple mfsmasters > to find the active master so that failover can happen without heartbeat and > ucarp. But this solution is not in MooseFS, and I am unsure if it is going > to be considered. Although, the metalogger is VERY close to doing this, I > think that all they need are a few consistency checks and the ability to > metalog to a master replica. > > > > > > On Thu, Jun 9, 2011 at 8:44 AM, Steve <st...@bo...> wrote: > > > > > > Is it at all possible that you could have more than one active master and > > they could be added or removed in the same way a chunk server can without > > affecting availability. Sharing workload ? > > > > > > > > > > > > > > > > > > > > -------Original Message------- > > > > > > > > From: Thomas S Hatch > > > > Date: 09/06/2011 15:20:07 > > > > To: Florent Bautista > > > > Cc: moo...@li... > > > > Subject: Re: [Moosefs-users] Failover of MFSMaster > > > > > > > > > > There are some solutions which involve synchronized virtual machines, many > > hyper-visors can do this. > > > > If you are planning on using the metalogger + mfsrestore there will always > > be a short failover lag. > > > > > > > > > > > > Personally, what I think would be the best option would be if the > metalogger > > > could populate the ram of a secondary read-only master. This is the same > > essential way that redis does it. > > > > > > > > > > > > The other option would be to set systems similar to mongo's HA solutions. > > > > > > > > > > > > Of course these solutions would require the MooseFS developers to implement > > them - I think that mfsmaster in-ram replication is something that MooseFS > > is very close to. > > > > > > > > > > > > Let us know what you decide on, there are a number of individuals using HA > > solutions for MooseFS. > > > > > > > > > > > > On Thu, Jun 9, 2011 at 5:06 AM, Florent Bautista <fl...@co...> > > wrote: > > > > > > > > Hi all, > > > > > > > > I have a question about failover of mfsmaster. > > > > > > > > Which solution is the best, for now ? > > > > > > > > I don't know which solution to choose between : > > > > > > > > - drdb+heartbeat > > > > - mfsmetalogger+mfsrestore > > > > > > > > What do you think about it ? is there other ways to failover mfsmaster > > (active sync of RAM between 2 hosts ?) ? > > > > > > > > > > > > -- > > > > > > > > > > > > Florent Bautista > > > > > > > > > > > > > > > > Ce message et ses éventuelles pièces jointes sont personnels, confidentiels > > et à l'usage exclusif de leur destinataire. > > > > > > Is vous n'êtes pas la personne à laquelle ce message EST destiné, veuillez > > noter que vous avez reçu ce courriel par erreur et qu'il vous EST > > > > strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou > > de copier ce message. > > > > > > > > This e-mail and any attachments hereto are strictly personal, confidential > > and intended solely for the addressee. > > > > If you are not the intended recipient, be advised that you have received > > this email in error and that any use, dissemination, forwarding, printing, > > or copying of this message is strictly prohibited. > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------------------- > > > > > > > EditLive Enterprise is the world's most technically advanced content > > > > authoring tool. Experience the power of Track Changes, Inline Image > > > > Editing and ensure content is compliant with Accessibility Checking. > > > > http://p.sf.net/sfu/ephox-dev2dev > > > > _______________________________________________ > > > > moosefs-users mailing list > > > > moo...@li... > > > > https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------------------- > > > > > > > EditLive Enterprise is the world's most technically advanced content > > > > authoring tool. Experience the power of Track Changes, Inline Image > > > > Editing and ensure content is compliant with Accessibility Checking. > > > > http://p.sf.net/sfu/ephox-dev2dev > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > moosefs-users mailing list > > > > moo...@li... > > > > https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > > > > > > > > > > > |
|
From: Steve <st...@bo...> - 2011-06-09 16:35:03
|
Ahh I see complex problem. A few mins googling and seeing what google use - they have 'chubby' -------Original Message------- From: Thomas S Hatch Date: 09/06/2011 16:16:35 To: Steve Cc: Florent Bautista; moo...@li... Subject: Re: [Moosefs-users] Failover of MFSMaster Unfortunately no. The problem is that the master holds all of the filesystem metadata, and if you had multiple master then you would need to guarantee that all masters have consistent data. This is a classic distributed database problem, and has still not been solved by projects like MySQL. There are few models out there for distributed master load, but the end result is almost always lower speed for the client, because more checks need to me put in place, or as is the case in a number of other distributed filesystems, a lot of the load is displaced to the client. I will agree that right now the master is the greatset point of failure and load issues in MooseFS. This is why I will still lobby for MooseFS to grate an active replicated master and clients that can query multiple mfsmasters to find the active master so that failover can happen without heartbeat and ucarp. But this solution is not in MooseFS, and I am unsure if it is going to be considered. Although, the metalogger is VERY close to doing this, I think that all they need are a few consistency checks and the ability to metalog to a master replica. On Thu, Jun 9, 2011 at 8:44 AM, Steve <st...@bo...> wrote: Is it at all possible that you could have more than one active master and they could be added or removed in the same way a chunk server can without affecting availability. Sharing workload ? -------Original Message------- From: Thomas S Hatch Date: 09/06/2011 15:20:07 To: Florent Bautista Cc: moo...@li... Subject: Re: [Moosefs-users] Failover of MFSMaster There are some solutions which involve synchronized virtual machines, many hyper-visors can do this. If you are planning on using the metalogger + mfsrestore there will always be a short failover lag. Personally, what I think would be the best option would be if the metalogger could populate the ram of a secondary read-only master. This is the same essential way that redis does it. The other option would be to set systems similar to mongo's HA solutions. Of course these solutions would require the MooseFS developers to implement them - I think that mfsmaster in-ram replication is something that MooseFS is very close to. Let us know what you decide on, there are a number of individuals using HA solutions for MooseFS. On Thu, Jun 9, 2011 at 5:06 AM, Florent Bautista <fl...@co...> wrote: Hi all, I have a question about failover of mfsmaster. Which solution is the best, for now ? I don't know which solution to choose between : - drdb+heartbeat - mfsmetalogger+mfsrestore What do you think about it ? is there other ways to failover mfsmaster (active sync of RAM between 2 hosts ?) ? -- Florent Bautista Ce message et ses éventuelles pièces jointes sont personnels, confidentiels et à l'usage exclusif de leur destinataire. Is vous n'êtes pas la personne à laquelle ce message EST destiné, veuillez noter que vous avez reçu ce courriel par erreur et qu'il vous EST strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message. This e-mail and any attachments hereto are strictly personal, confidential and intended solely for the addressee. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this message is strictly prohibited. ----------------------------------------------------------------------------- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ moosefs-users mailing list moo...@li... https://lists.sourceforge.net/lists/listinfo/moosefs-users ----------------------------------------------------------------------------- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ moosefs-users mailing list moo...@li... https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: Thomas S H. <tha...@gm...> - 2011-06-09 15:17:41
|
Unfortunately no. The problem is that the master holds all of the filesystem metadata, and if you had multiple master then you would need to guarantee that all masters have consistent data. This is a classic distributed database problem, and has still not been solved by projects like MySQL. There are few models out there for distributed master load, but the end result is almost always lower speed for the client, because more checks need to me put in place, or as is the case in a number of other distributed filesystems, a lot of the load is displaced to the client. I will agree that right now the master is the greatset point of failure and load issues in MooseFS. This is why I will still lobby for MooseFS to grate an active replicated master and clients that can query multiple mfsmasters to find the active master so that failover can happen without heartbeat and ucarp. But this solution is not in MooseFS, and I am unsure if it is going to be considered. Although, the metalogger is VERY close to doing this, I think that all they need are a few consistency checks and the ability to metalog to a master replica. On Thu, Jun 9, 2011 at 8:44 AM, Steve <st...@bo...> wrote: > > Is it at all possible that you could have more than one active master and > they could be added or removed in the same way a chunk server can without > affecting availability. Sharing workload ? > > > > > > > > > > -------Original Message------- > > > > From: Thomas S Hatch > > Date: 09/06/2011 15:20:07 > > To: Florent Bautista > > Cc: moo...@li... > > Subject: Re: [Moosefs-users] Failover of MFSMaster > > > > There are some solutions which involve synchronized virtual machines, many > hyper-visors can do this. > > If you are planning on using the metalogger + mfsrestore there will always > be a short failover lag. > > > > > > Personally, what I think would be the best option would be if the > metalogger > could populate the ram of a secondary read-only master. This is the same > essential way that redis does it. > > > > > > The other option would be to set systems similar to mongo's HA solutions. > > > > > > Of course these solutions would require the MooseFS developers to implement > them - I think that mfsmaster in-ram replication is something that MooseFS > is very close to. > > > > > > Let us know what you decide on, there are a number of individuals using HA > solutions for MooseFS. > > > > > > On Thu, Jun 9, 2011 at 5:06 AM, Florent Bautista <fl...@co...> > wrote: > > > > Hi all, > > > > I have a question about failover of mfsmaster. > > > > Which solution is the best, for now ? > > > > I don't know which solution to choose between : > > > > - drdb+heartbeat > > - mfsmetalogger+mfsrestore > > > > What do you think about it ? is there other ways to failover mfsmaster > (active sync of RAM between 2 hosts ?) ? > > > > > > -- > > > > > > Florent Bautista > > > > > > > > Ce message et ses éventuelles pièces jointes sont personnels, confidentiels > et à l'usage exclusif de leur destinataire. > > Is vous n'êtes pas la personne à laquelle ce message EST destiné, veuillez > noter que vous avez reçu ce courriel par erreur et qu'il vous EST > strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou > de copier ce message. > > > > This e-mail and any attachments hereto are strictly personal, confidential > and intended solely for the addressee. > > If you are not the intended recipient, be advised that you have received > this email in error and that any use, dissemination, forwarding, printing, > or copying of this message is strictly prohibited. > > > > > > > > > > > ----------------------------------------------------------------------------- > > > EditLive Enterprise is the world's most technically advanced content > > authoring tool. Experience the power of Track Changes, Inline Image > > Editing and ensure content is compliant with Accessibility Checking. > > http://p.sf.net/sfu/ephox-dev2dev > > _______________________________________________ > > moosefs-users mailing list > > moo...@li... > > https://lists.sourceforge.net/lists/listinfo/moosefs-users > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------------------- > > > EditLive Enterprise is the world's most technically advanced content > > authoring tool. Experience the power of Track Changes, Inline Image > > Editing and ensure content is compliant with Accessibility Checking. > > http://p.sf.net/sfu/ephox-dev2dev > > > > > > > > > > > > _______________________________________________ > > 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.
