Menu
▾
▴
moosefs-users — Mailing list for MooseFS Users
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(20) |
Feb
(11) |
Mar
(11) |
Apr
(9) |
May
(22) |
Jun
(85) |
Jul
(94) |
Aug
(80) |
Sep
(72) |
Oct
(64) |
Nov
(69) |
Dec
(89) |
| 2011 |
Jan
(72) |
Feb
(109) |
Mar
(116) |
Apr
(117) |
May
(117) |
Jun
(102) |
Jul
(91) |
Aug
(72) |
Sep
(51) |
Oct
(41) |
Nov
(55) |
Dec
(74) |
| 2012 |
Jan
(45) |
Feb
(77) |
Mar
(99) |
Apr
(113) |
May
(132) |
Jun
(75) |
Jul
(70) |
Aug
(58) |
Sep
(58) |
Oct
(37) |
Nov
(51) |
Dec
(15) |
| 2013 |
Jan
(28) |
Feb
(16) |
Mar
(25) |
Apr
(38) |
May
(23) |
Jun
(39) |
Jul
(42) |
Aug
(19) |
Sep
(41) |
Oct
(31) |
Nov
(18) |
Dec
(18) |
| 2014 |
Jan
(17) |
Feb
(19) |
Mar
(39) |
Apr
(16) |
May
(10) |
Jun
(13) |
Jul
(17) |
Aug
(13) |
Sep
(8) |
Oct
(53) |
Nov
(23) |
Dec
(7) |
| 2015 |
Jan
(35) |
Feb
(13) |
Mar
(14) |
Apr
(56) |
May
(8) |
Jun
(18) |
Jul
(26) |
Aug
(33) |
Sep
(40) |
Oct
(37) |
Nov
(24) |
Dec
(20) |
| 2016 |
Jan
(38) |
Feb
(20) |
Mar
(25) |
Apr
(14) |
May
(6) |
Jun
(36) |
Jul
(27) |
Aug
(19) |
Sep
(36) |
Oct
(24) |
Nov
(15) |
Dec
(16) |
| 2017 |
Jan
(8) |
Feb
(13) |
Mar
(17) |
Apr
(20) |
May
(28) |
Jun
(10) |
Jul
(20) |
Aug
(3) |
Sep
(18) |
Oct
(8) |
Nov
|
Dec
(5) |
| 2018 |
Jan
(15) |
Feb
(9) |
Mar
(12) |
Apr
(7) |
May
(123) |
Jun
(41) |
Jul
|
Aug
(14) |
Sep
|
Oct
(15) |
Nov
|
Dec
(7) |
| 2019 |
Jan
(2) |
Feb
(9) |
Mar
(2) |
Apr
(9) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(12) |
Dec
(2) |
| 2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(18) |
Oct
(2) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(5) |
Oct
(5) |
Nov
(3) |
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Piotr R. K. <pio...@mo...> - 2015-01-21 11:29:54
|
Dear Chenr, We are very happy that you're using MooseFS :) 1.6.25 is a very old and not supported version of MooseFS. You should *immediately* upgrade your whole instance to the *MooseFS 2.0.48 CE*, because in 2.0.x branch a lot of improvements and bug fixes has been made. Please keep in mind, that supported way to upgrade your instance is: Your version -> *1.6.27-5* -> 2.0.x CE, so you firstly need to upgrade to 1.6.27-5 and then to 2.0.48 CE. The whole upgrade process is described in MooseFS Upgrade Guide[1], so please refer to this document. I also very recommend reading MooseFS 2.0 Step-by-Step Installation Guide[2]. Also, at http://get.moosefs.com[3] you can find useful information about installing MooseFS from packages, so now you don't need to compile MooseFS yourself (but you still can if you want, because sources of MooseFS 2.0.x CE are available). In case of any questions, please don't hesitate to contact our Technical Support Department at dw...@mo...[4]. -- Best regards, Piotr Robert Konopelko *MooseFS Technical Support Engineer *| moosefs.com[5] Dear moosefs-Developers : I am a moosefs-user, our moosefs version is 1.6.25 ,stored 71347651 chunks, and have one mfsmaster server,one mfsmetalogger server,thirty-one chunkservers and mfsclients(mfschunkserver and mfsclient installed on the same server). I meet a thorny problem : all servers attached to the same switch , the network connection between the server properly ,the network in stable condition, but all mfschunkservers ,mfsclients and mfsmetalogger servers disconnected the mfsmaster on the same time, the mfsmasterserver's log is as follows figure: I can not find the cause of the problem , so restart the mfsmaster , then everything back to normal .This happens several times, after restart mfsmaster ,all services back to normal. Can solve this problem by upgrade version to 1.6.27-5 ? Is the version 1.6.27-5 stable? Which version should i upgrade? Sincerely request your assistance,please give me help ,thank you very much . Best regards! -------------------- *陈嵘* 网宿科技股份有限公司 厦门分公司 CDN运营中心 mobile:18965810348 E-mail:ch...@ch...[6] http://www.chinanetcenter.com[7] 分公司：北京-上海-广州-深圳 咨询电话：800-820-0001 卓越的互联网业务平台提供商 -------------------- -------- [1] http://pro.hit.gemius.pl/hitredir/id=p4M1jTM4nRhU008M3Fe_sOUC3wjpXEbik3RJMrUmhjn.l7/et=1/extra=moosefsManual%3DupgradeGuide/url=http://moosefs.com/Content/Downloads/moosefs-upgrade.pdf [2] http://pro.hit.gemius.pl/hitredir/id=p4M1jTM4nRhU008M3Fe_sOUC3wjpXEbik3RJMrUmhjn.l7/et=1/extra=moosefsManual%3DstepByStep/url=http://moosefs.com/Content/Downloads/moosefs-installation.pdf [3] http://get.moosefs.com [4] mailto:dw...@mo... [5] http://moosefs.com [6] mailto:ch...@ch... [7] http://www.chinanetcenter.com/ |
|
From: 陈嵘 <ch...@ch...> - 2015-01-21 11:03:35
|
Dear moosefs-Developers :
I am a moosefs-user, our moosefs version is 1.6.25 ,stored 71347651 chunks, and have one mfsmaster server,one mfsmetalogger server,thirty-one chunkservers and mfsclients(mfschunkserver and mfsclient installed on the same server).
I meet a thorny problem :
all servers attached to the same switch ,
the network connection between the server properly ,the network in stable condition, but all mfschunkservers ,mfsclients and mfsmetalogger servers disconnected the mfsmaster on the same time,
the mfsmasterserver's log is as follows figure:
I can not find the cause of the problem , so restart the mfsmaster , then everything back to normal .This happens several times, after restart mfsmaster ,all services back to normal.
Can solve this problem by upgrade version to 1.6.27-5 ? Is the version 1.6.27-5 stable? Which version should i upgrade?
Sincerely request your assistance,please give me help ,thank you very much .
Best regards!
陈嵘
网宿科技股份有限公司 厦门分公司 CDN运营中心
mobile:18965810348
E-mail:ch...@ch...
http://www.chinanetcenter.com分公司：北京-上海-广州-深圳
咨询电话：800-820-0001
卓越的互联网业务平台提供商 |
|
From: Tom I. H. <ti...@ha...> - 2015-01-12 07:36:12
|
Jakub Kruszona-Zawadzki <jak...@ge...> writes: > No. Master should always change ctime when anything is changing in > inode data. ...except if the change is to update atime. Lots of backup software will consider the file changed, and in need of a new backup, if ctime has changed. That was the situation that alerted me to the problem in the first place. > Fuse on NetBSD shouldn't change atime and mtime itself using setattr. I tend to agree. It is, however, perfectly legal for the client to do this, and if the only change is an update of atime, that should not imply a ctime change. I still think the patch I sent earlier creates a generally valid semantics for these updates. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier" |
|
From: Jakub Kruszona-Z. <jak...@ge...> - 2015-01-12 07:33:06
|
On 9 Jan, 2015, at 19:27, Davies Liu <dav...@gm...> wrote:
> On Fri, Jan 9, 2015 at 5:02 AM, Tom Ivar Helbekkmo <ti...@ha...> wrote:
>> I've noticed something really weird happening with atime updates while
>> playing with MooseFS 2.0.45 with the server processes on NetBSD systems,
>> and clients on NetBSD and on Ubuntu, and I'm wondering how much of this
>> is caused by MooseFS, how much by the client operating systems.
>>
>> Specifically, this is NetBSD 7.99.2 (NetBSD-current as of about a month
>> ago), Ubuntu 14.10 (completely up-to-date), MooseFS 2.0.45 (compiled
>> locally on all systems), FUSE 2.9.3 on NetBSD, 2.9.2 on Ubuntu.
>>
>> The initial problem:
>>
>> I noticed that incremental backups of my MooseFS-mounted file system
>> under NetBSD always backed up all files. It turned out that when they
>> were read by the backup program, both atime and ctime were updated.
>> This is certainly not right.
>>
>> Things get weird:
>>
>> A quick test showed that 'cat foo.bar > /dev/null' on a NetBSD client
>> would update both atime and ctime. Doing the same thing on the Ubuntu
>> client would update neither! In both cases, the file system has been
>> mounted using mfsmount with no extra options, so *not* 'noatime'. So
>> both clients are misbehaving, but in different ways.
>>
>> Things get weirder:
>>
>> Changing the NetBSD client mount to 'mfsmount -o noatime' causes the
>> above cat command to not update ctime, but it still updates atime! This
>> is certainly what I want to achieve, and therefore what I'm currently
>> running with, but it is not correct handling of the noatime option.
>>
>> The .oplog output from the above experiments:
>>
>> On Linux client:
>>
>> # cat foo.bar > /dev/null
>>
>> 01.08 08:20:20.153311: uid:4229 gid:4229 pid:16822 cmd:getattr (1296): OK (0.0,[drwxr-xr-x:0040755,2,4229,4229,1420701614,1420658441,1420658441,1002157])
>> 01.08 08:20:20.161381: uid:4229 gid:4229 pid:16876 cmd:lookup (1296,foo.bar): OK (0.0,1305,0.0,[-rw-rw-r--:0100664,1,4229,4229,1420689285,1420545727,1420689285,22092])
>> 01.08 08:20:20.167891: uid:4229 gid:4229 pid:16876 cmd:open (1305): OK (0,0)
>> 01.08 08:20:20.174262: uid:4229 gid:4229 pid:16876 cmd:getattr (1305): OK (0.0,[-rw-rw-r--:0100664,1,4229,4229,1420689285,1420545727,1420689285,22092])
>> 01.08 08:20:20.180500: uid:4229 gid:4229 pid:16876 cmd:getattr (1305): OK (0.0,[-rw-rw-r--:0100664,1,4229,4229,1420689285,1420545727,1420689285,22092])
>> 01.08 08:20:20.285700: uid:4229 gid:4229 pid:16876 cmd:read (1305,24576,0): OK (22092)
>> 01.08 08:20:20.292289: uid:4229 gid:4229 pid:16876 cmd:getattr (1305): OK (0.0,[-rw-rw-r--:0100664,1,4229,4229,1420701620,1420545727,1420689285,22092])
>> 01.08 08:20:20.292390: uid:4229 gid:4229 pid:16876 cmd:flush (1305): OK
>> 01.08 08:20:20.292497: uid:0 gid:0 pid:0 cmd:release (1305): OK
>>
>> On NetBSD client:
>>
>> # cat foo.bar > /dev/null
>>
>> 01.08 08:23:34.489589: uid:501 gid:20 pid:25694 cmd:lookup (1296,foo.bar): OK (0.0,1305,1.0,[-rw-rw-r--:0100664,1,501,20,1420701673,1420545727,1420701673,22092])
>> 01.08 08:23:34.490756: uid:501 gid:20 pid:25694 cmd:open (1305): OK (0,1)
>> 01.08 08:23:34.495376: uid:0 gid:0 pid:25694 cmd:read (1305,8192,0): OK (8192)
>> 01.08 08:23:34.497033: uid:0 gid:0 pid:25694 cmd:read (1305,8192,8192): OK (8192)
>> 01.08 08:23:34.498341: uid:0 gid:0 pid:25694 cmd:read (1305,5708,16384): OK (5708)
>> 01.08 08:23:34.498698: uid:0 gid:0 pid:25694 cmd:release (1305): OK
>> 01.08 08:23:34.499275: uid:0 gid:0 pid:25694 cmd:setattr (1305,0x30,[---------:00000,0,0,1420701814,1420545727,0]): OK (1.0,[-rw-rw-r--:0100664,1,501,20,1420701814,1420545727,1420701814,22092])
>
> The setattr() will update the ctime in master. The master should check
> and do not update mtime/ctime when only atime is updated.
No. Master should always change ctime when anything is changing in inode data. Fuse on NetBSD shouldn't change atime and mtime itself using setattr.
Example on Linux:
root@ts02:/var/lib/mfs# stat stats.mfs
File: 'stats.mfs'
Size: 3410488 Blocks: 6664 IO Block: 4096 regular file
Device: 805h/2053d Inode: 37227104 Links: 1
Access: (0640/-rw-r-----) Uid: ( 105/ mfs) Gid: ( 111/ mfs)
Access: 2015-01-09 13:30:56.396349987 +0100
Modify: 2015-01-09 13:30:55.000383078 +0100
Change: 2015-01-09 13:30:55.000383078 +0100
Birth: -
root@ts02:/var/lib/mfs# touch -a stats.mfs
root@ts02:/var/lib/mfs# stat stats.mfs
File: 'stats.mfs'
Size: 3410488 Blocks: 6664 IO Block: 4096 regular file
Device: 805h/2053d Inode: 37227104 Links: 1
Access: (0640/-rw-r-----) Uid: ( 105/ mfs) Gid: ( 111/ mfs)
Access: 2015-01-12 07:30:50.826045070 +0100
Modify: 2015-01-09 13:30:55.000383078 +0100
Change: 2015-01-12 07:30:50.826045070 +0100
Birth: -
As you can see setattr with atime only (touch -a) changed atime and ctime together (ext4). This is correct behaviour according to POSIX rules.
It might be possible to create special patch for NetBSD, but anyway this is a bug in FUSE on NetBSD. The only patch I can do is not to change ctime during atime/mtime change on NetBSD - in such case "touch" will never change ctime on NetBSD which is not correct, but probably much better than current behaviour.
>
>> On NetBSD client, with noatime option:
>>
>> # cat foo.bar > /dev/null
>>
>> 01.09 13:00:30.949264: uid:501 gid:20 pid:20198 cmd:lookup (1296,foo.bar): OK (0.0,1343,1.0,[-rw-rw-r--:0100664,1,501,20,1420804740,1420709297,1420709297,22236])
>> 01.09 13:00:30.950398: uid:501 gid:20 pid:20198 cmd:open (1343): OK (0,1)
>
> master should update the atime when open(), maybe it's a bug in 2.0.45
No. Open never changes atime/mtime on ext4:
root@ts02:/var/lib/mfs# python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import posix
>>> posix.stat("stats.mfs")
posix.stat_result(st_mode=33184, st_ino=37227104, st_dev=2053L, st_nlink=1, st_uid=105, st_gid=111, st_size=3410488, st_atime=1421044250, st_mtime=1420806655, st_ctime=1421044250)
>>> a = posix.open("stats.mfs",posix.O_RDONLY)
>>> posix.stat("stats.mfs")
posix.stat_result(st_mode=33184, st_ino=37227104, st_dev=2053L, st_nlink=1, st_uid=105, st_gid=111, st_size=3410488, st_atime=1421044250, st_mtime=1420806655, st_ctime=1421044250)
>>> posix.read(a,12)
'\x00\x01\x00\x00\x00\x00\x10\x00\x00\x00\x00\x1a'
>>> posix.stat("stats.mfs")
posix.stat_result(st_mode=33184, st_ino=37227104, st_dev=2053L, st_nlink=1, st_uid=105, st_gid=111, st_size=3410488, st_atime=1421044545, st_mtime=1420806655, st_ctime=1421044250)
>>>
As you can see st_atime is changed after first read, not open.
The problem of not updating atime on Linux may be caused by reading whole file from the cache. When there is sequence "open,read,release" then atime always should be changed (if it isn't then it is a bug in moosefs), but when file is read from the internal cache then sequence will be "open,release" - in such case master shouldn't update atime (POSIX rules) and likely there is no way to get info from the kernel that the file was actually read between open and release.
>
>> 01.09 13:00:30.955347: uid:0 gid:0 pid:20198 cmd:read (1343,8192,0): OK (8192)
>> 01.09 13:00:30.957488: uid:0 gid:0 pid:20198 cmd:read (1343,8192,8192): OK (8192)
>> 01.09 13:00:30.959370: uid:0 gid:0 pid:20198 cmd:read (1343,5852,16384): OK (5852)
>> 01.09 13:00:30.959671: uid:0 gid:0 pid:20198 cmd:release (1343): OK
>> -tih
>> --
>> It doesn't matter how beautiful your theory is, it doesn't matter how smart
>> you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net
>> _______________________________________________
>> moosefs-users mailing list
>> moo...@li...
>> https://lists.sourceforge.net/lists/listinfo/moosefs-users
>
>
>
> --
> - Davies
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> moosefs-users mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moosefs-users
--
Regards,
Jakub Kruszona-Zawadzki
- - - - - - - - - - - - - - - -
Segmentation fault (core dumped)
Phone: +48 602 212 039
|
|
From: Tom I. H. <ti...@ha...> - 2015-01-12 07:13:26
|
Sending this again, since it seems not to have made it onto the list:
Davies Liu <dav...@gm...> writes:
> On Fri, Jan 9, 2015 at 5:02 AM, Tom Ivar Helbekkmo
> <ti...@ha...> wrote:
>> 01.08 08:23:34.499275: uid:0 gid:0 pid:25694 cmd:setattr
>> (1305,0x30,[---------:00000,0,0,1420701814,1420545727,0]): OK
>> (1.0,[-rw-rw-r--:0100664,1,501,20,1420701814,1420545727,1420701814,22092])
>
> The setattr() will update the ctime in master. The master should check
> and do not update mtime/ctime when only atime is updated.
I agree. I don't know why this setattr, whose purpose is to update the
atime, is being generated with an explicit setting of mtime to the same
value that it already has. I haven't been able to figure out what's
actually doing that.
However, the change to fix it in the mfsmaster is really simple:
# Make 2.0.45 CE not update ctime if the only change to the file
# attributes is an update of the atime. At the same time, make it
# tolerant of software that explicitly sets mtime to what it already
# was, and not let that "change" make it update ctime, either.
#
--- mfsmaster/filesystem.c~ 2014-12-24 13:13:31.000000000 +0100
+++ mfsmaster/filesystem.c 2015-01-11 17:56:00.000000000 +0100
@@ -4138,10 +4138,16 @@
p->atime = attratime;
}
if (setmask&SET_MTIME_FLAG) {
- p->mtime = attrmtime;
+ if (p->mtime == attrmtime) {
+ setmask &= ~SET_MTIME_FLAG;
+ } else {
+ p->mtime = attrmtime;
+ }
}
changelog("%"PRIu32"|ATTR(%"PRIu32",%"PRIu16",%"PRIu32",%"PRIu32",%"PRIu32",%"PRIu32")",ts,inode,(uint16_t)(p->mode),p->uid,p->gid,p->atime,p->mtime);
- p->ctime = ts;
+ if ((setmask & ~SET_ATIME_FLAG) != 0) {
+ p->ctime = ts;
+ }
fsnodes_fill_attr(p,NULL,uid,gid[0],auid,agid,sesflags,attr);
stats_setattr++;
return STATUS_OK;
>> 01.09 13:00:30.950398: uid:501 gid:20 pid:20198 cmd:open (1343): OK (0,1)
>
> master should update the atime when open(),
No, this should be the client's decision, where the client typically
turns it off to avoid the extra inode writes, and improve performance.
> maybe it's a bug in 2.0.45
It's not a bug, after all. Turns out this is a Linux thing I wasn't
aware of: Linux defaults to a scheme where it will only update atime on
reading a file if the old atime is older than the current mtime and/or
ctime, or the old atime is more than 24 hours in the past. This makes
atime answer the question "has the file been read since it was last
changed", thus keeping most of the efficiency gains of a noatime mount,
but breaking fewer applications. I've verified that my MooseFS Ubuntu
client behaves like that.
So, with the above patch, everything works exactly the way I want it to.
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
|
|
From: Davies L. <dav...@gm...> - 2015-01-09 18:27:30
|
On Fri, Jan 9, 2015 at 5:02 AM, Tom Ivar Helbekkmo <ti...@ha...> wrote: > I've noticed something really weird happening with atime updates while > playing with MooseFS 2.0.45 with the server processes on NetBSD systems, > and clients on NetBSD and on Ubuntu, and I'm wondering how much of this > is caused by MooseFS, how much by the client operating systems. > > Specifically, this is NetBSD 7.99.2 (NetBSD-current as of about a month > ago), Ubuntu 14.10 (completely up-to-date), MooseFS 2.0.45 (compiled > locally on all systems), FUSE 2.9.3 on NetBSD, 2.9.2 on Ubuntu. > > The initial problem: > > I noticed that incremental backups of my MooseFS-mounted file system > under NetBSD always backed up all files. It turned out that when they > were read by the backup program, both atime and ctime were updated. > This is certainly not right. > > Things get weird: > > A quick test showed that 'cat foo.bar > /dev/null' on a NetBSD client > would update both atime and ctime. Doing the same thing on the Ubuntu > client would update neither! In both cases, the file system has been > mounted using mfsmount with no extra options, so *not* 'noatime'. So > both clients are misbehaving, but in different ways. > > Things get weirder: > > Changing the NetBSD client mount to 'mfsmount -o noatime' causes the > above cat command to not update ctime, but it still updates atime! This > is certainly what I want to achieve, and therefore what I'm currently > running with, but it is not correct handling of the noatime option. > > The .oplog output from the above experiments: > > On Linux client: > > # cat foo.bar > /dev/null > > 01.08 08:20:20.153311: uid:4229 gid:4229 pid:16822 cmd:getattr (1296): OK (0.0,[drwxr-xr-x:0040755,2,4229,4229,1420701614,1420658441,1420658441,1002157]) > 01.08 08:20:20.161381: uid:4229 gid:4229 pid:16876 cmd:lookup (1296,foo.bar): OK (0.0,1305,0.0,[-rw-rw-r--:0100664,1,4229,4229,1420689285,1420545727,1420689285,22092]) > 01.08 08:20:20.167891: uid:4229 gid:4229 pid:16876 cmd:open (1305): OK (0,0) > 01.08 08:20:20.174262: uid:4229 gid:4229 pid:16876 cmd:getattr (1305): OK (0.0,[-rw-rw-r--:0100664,1,4229,4229,1420689285,1420545727,1420689285,22092]) > 01.08 08:20:20.180500: uid:4229 gid:4229 pid:16876 cmd:getattr (1305): OK (0.0,[-rw-rw-r--:0100664,1,4229,4229,1420689285,1420545727,1420689285,22092]) > 01.08 08:20:20.285700: uid:4229 gid:4229 pid:16876 cmd:read (1305,24576,0): OK (22092) > 01.08 08:20:20.292289: uid:4229 gid:4229 pid:16876 cmd:getattr (1305): OK (0.0,[-rw-rw-r--:0100664,1,4229,4229,1420701620,1420545727,1420689285,22092]) > 01.08 08:20:20.292390: uid:4229 gid:4229 pid:16876 cmd:flush (1305): OK > 01.08 08:20:20.292497: uid:0 gid:0 pid:0 cmd:release (1305): OK > > On NetBSD client: > > # cat foo.bar > /dev/null > > 01.08 08:23:34.489589: uid:501 gid:20 pid:25694 cmd:lookup (1296,foo.bar): OK (0.0,1305,1.0,[-rw-rw-r--:0100664,1,501,20,1420701673,1420545727,1420701673,22092]) > 01.08 08:23:34.490756: uid:501 gid:20 pid:25694 cmd:open (1305): OK (0,1) > 01.08 08:23:34.495376: uid:0 gid:0 pid:25694 cmd:read (1305,8192,0): OK (8192) > 01.08 08:23:34.497033: uid:0 gid:0 pid:25694 cmd:read (1305,8192,8192): OK (8192) > 01.08 08:23:34.498341: uid:0 gid:0 pid:25694 cmd:read (1305,5708,16384): OK (5708) > 01.08 08:23:34.498698: uid:0 gid:0 pid:25694 cmd:release (1305): OK > 01.08 08:23:34.499275: uid:0 gid:0 pid:25694 cmd:setattr (1305,0x30,[---------:00000,0,0,1420701814,1420545727,0]): OK (1.0,[-rw-rw-r--:0100664,1,501,20,1420701814,1420545727,1420701814,22092]) The setattr() will update the ctime in master. The master should check and do not update mtime/ctime when only atime is updated. > On NetBSD client, with noatime option: > > # cat foo.bar > /dev/null > > 01.09 13:00:30.949264: uid:501 gid:20 pid:20198 cmd:lookup (1296,foo.bar): OK (0.0,1343,1.0,[-rw-rw-r--:0100664,1,501,20,1420804740,1420709297,1420709297,22236]) > 01.09 13:00:30.950398: uid:501 gid:20 pid:20198 cmd:open (1343): OK (0,1) master should update the atime when open(), maybe it's a bug in 2.0.45 > 01.09 13:00:30.955347: uid:0 gid:0 pid:20198 cmd:read (1343,8192,0): OK (8192) > 01.09 13:00:30.957488: uid:0 gid:0 pid:20198 cmd:read (1343,8192,8192): OK (8192) > 01.09 13:00:30.959370: uid:0 gid:0 pid:20198 cmd:read (1343,5852,16384): OK (5852) > 01.09 13:00:30.959671: uid:0 gid:0 pid:20198 cmd:release (1343): OK > -tih > -- > It doesn't matter how beautiful your theory is, it doesn't matter how smart > you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users -- - Davies |
|
From: Tom I. H. <ti...@ha...> - 2015-01-09 13:02:39
|
I've noticed something really weird happening with atime updates while playing with MooseFS 2.0.45 with the server processes on NetBSD systems, and clients on NetBSD and on Ubuntu, and I'm wondering how much of this is caused by MooseFS, how much by the client operating systems. Specifically, this is NetBSD 7.99.2 (NetBSD-current as of about a month ago), Ubuntu 14.10 (completely up-to-date), MooseFS 2.0.45 (compiled locally on all systems), FUSE 2.9.3 on NetBSD, 2.9.2 on Ubuntu. The initial problem: I noticed that incremental backups of my MooseFS-mounted file system under NetBSD always backed up all files. It turned out that when they were read by the backup program, both atime and ctime were updated. This is certainly not right. Things get weird: A quick test showed that 'cat foo.bar > /dev/null' on a NetBSD client would update both atime and ctime. Doing the same thing on the Ubuntu client would update neither! In both cases, the file system has been mounted using mfsmount with no extra options, so *not* 'noatime'. So both clients are misbehaving, but in different ways. Things get weirder: Changing the NetBSD client mount to 'mfsmount -o noatime' causes the above cat command to not update ctime, but it still updates atime! This is certainly what I want to achieve, and therefore what I'm currently running with, but it is not correct handling of the noatime option. The .oplog output from the above experiments: On Linux client: # cat foo.bar > /dev/null 01.08 08:20:20.153311: uid:4229 gid:4229 pid:16822 cmd:getattr (1296): OK (0.0,[drwxr-xr-x:0040755,2,4229,4229,1420701614,1420658441,1420658441,1002157]) 01.08 08:20:20.161381: uid:4229 gid:4229 pid:16876 cmd:lookup (1296,foo.bar): OK (0.0,1305,0.0,[-rw-rw-r--:0100664,1,4229,4229,1420689285,1420545727,1420689285,22092]) 01.08 08:20:20.167891: uid:4229 gid:4229 pid:16876 cmd:open (1305): OK (0,0) 01.08 08:20:20.174262: uid:4229 gid:4229 pid:16876 cmd:getattr (1305): OK (0.0,[-rw-rw-r--:0100664,1,4229,4229,1420689285,1420545727,1420689285,22092]) 01.08 08:20:20.180500: uid:4229 gid:4229 pid:16876 cmd:getattr (1305): OK (0.0,[-rw-rw-r--:0100664,1,4229,4229,1420689285,1420545727,1420689285,22092]) 01.08 08:20:20.285700: uid:4229 gid:4229 pid:16876 cmd:read (1305,24576,0): OK (22092) 01.08 08:20:20.292289: uid:4229 gid:4229 pid:16876 cmd:getattr (1305): OK (0.0,[-rw-rw-r--:0100664,1,4229,4229,1420701620,1420545727,1420689285,22092]) 01.08 08:20:20.292390: uid:4229 gid:4229 pid:16876 cmd:flush (1305): OK 01.08 08:20:20.292497: uid:0 gid:0 pid:0 cmd:release (1305): OK On NetBSD client: # cat foo.bar > /dev/null 01.08 08:23:34.489589: uid:501 gid:20 pid:25694 cmd:lookup (1296,foo.bar): OK (0.0,1305,1.0,[-rw-rw-r--:0100664,1,501,20,1420701673,1420545727,1420701673,22092]) 01.08 08:23:34.490756: uid:501 gid:20 pid:25694 cmd:open (1305): OK (0,1) 01.08 08:23:34.495376: uid:0 gid:0 pid:25694 cmd:read (1305,8192,0): OK (8192) 01.08 08:23:34.497033: uid:0 gid:0 pid:25694 cmd:read (1305,8192,8192): OK (8192) 01.08 08:23:34.498341: uid:0 gid:0 pid:25694 cmd:read (1305,5708,16384): OK (5708) 01.08 08:23:34.498698: uid:0 gid:0 pid:25694 cmd:release (1305): OK 01.08 08:23:34.499275: uid:0 gid:0 pid:25694 cmd:setattr (1305,0x30,[---------:00000,0,0,1420701814,1420545727,0]): OK (1.0,[-rw-rw-r--:0100664,1,501,20,1420701814,1420545727,1420701814,22092]) On NetBSD client, with noatime option: # cat foo.bar > /dev/null 01.09 13:00:30.949264: uid:501 gid:20 pid:20198 cmd:lookup (1296,foo.bar): OK (0.0,1343,1.0,[-rw-rw-r--:0100664,1,501,20,1420804740,1420709297,1420709297,22236]) 01.09 13:00:30.950398: uid:501 gid:20 pid:20198 cmd:open (1343): OK (0,1) 01.09 13:00:30.955347: uid:0 gid:0 pid:20198 cmd:read (1343,8192,0): OK (8192) 01.09 13:00:30.957488: uid:0 gid:0 pid:20198 cmd:read (1343,8192,8192): OK (8192) 01.09 13:00:30.959370: uid:0 gid:0 pid:20198 cmd:read (1343,5852,16384): OK (5852) 01.09 13:00:30.959671: uid:0 gid:0 pid:20198 cmd:release (1343): OK -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
|
From: Piotr R. K. <pio...@mo...> - 2015-01-04 11:41:37
|
Hello, it was a mistake, thank you for pointing it out. It has been already fixed - feel free to download the Upgrade Guide: http://moosefs.com/Content/Downloads/moosefs-upgrade.pdf[1] :) -- Best regards, Piotr Robert Konopelko *MooseFS Technical Support Engineer* pio...@mo...[2] | moosefs.com[3] I find the content of upgrade guide is same as the user's manual. I'm no offence, but is that what it is or a mistake? It's marked in the picture in the attachment. -------- [1] http://moosefs.com/Content/Downloads/moosefs-upgrade.pdf [2] mailto:pio...@mo... [3] http://moosefs.com |
|
From: 余弦 <yux...@16...> - 2015-01-04 07:00:07
|
I find the content of upgrade guide is same as the user's manual. I'm no offence, but is that what it is or a mistake? It's marked in the picture in the attachment. |
|
From: Tom I. H. <ti...@ha...> - 2014-12-30 21:13:25
|
Testing shows that this has been fixed in 2.0.45. -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
|
From: Tom I. H. <ti...@ha...> - 2014-12-30 21:13:12
|
Testing shows that this has been fixed in 2.0.45. -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
|
From: Tom I. H. <ti...@ha...> - 2014-12-23 14:35:42
|
Well, I don't know *why*, because I don't understand the protocol, but
with a simple change, I'm now seeing:
with "mapall=tih":
root mapped to 501:dialout ; users mapped to 501:dialout
with "maproot=root,mapall=tih":
root mapped to root:root ; users mapped to 501:dialout
The change is simply this (because I found out that for me, whether the
client is running NetBSD or Ubuntu, i is 35 the only time that test is
executed during the mounting):
--- mfsmount/mastercomm.c~ 2014-11-27 10:18:30.000000000 +0100
+++ mfsmount/mastercomm.c 2014-12-23 15:27:23.000000000 +0100
@@ -1094,7 +1094,7 @@
if (!cargs->meta) {
rootuid = get32bit(&rptr);
rootgid = get32bit(&rptr);
- if (i==21) {
+ if (i==35) {
mapalluid = get32bit(&rptr);
mapallgid = get32bit(&rptr);
} else {
-tih
--
It doesn't matter how beautiful your theory is, it doesn't matter how smart
you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman
|
|
From: Tom I. H. <ti...@ha...> - 2014-12-23 10:26:05
|
...oh, and another data point: the "mfscli -SEX" output is correct on both the master and the client. -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
|
From: Tom I. H. <ti...@ha...> - 2014-12-23 10:19:43
|
The below patch changes the behaviour of the mfsmaster's use of the
mfsexports.cfg configuration slightly. It adds awareness of the
specificity of the address range match, so that the mfsmaster will
always prefer a more specific match (that is, a shorter range of
addresses including the target one). This criterion is placed at the
head of the comparison, thus giving it top priority.
The existing test for path length (prefering a more specific path match)
is moved up to second priority. This feels proper to me: begin by
finding the best match for the connecting client address, then
differentiate between equally good matches by looking at the path
prefix, and finally, if they're still equal, study the options,
choosing, say, password protected write access over unauthenticated read
only access.
With the patch, this works as one would expect:
10.1.2.0/24 / rw,alldirs,maproot=root
10.1.2.8/32 / rw,alldirs,maproot=root,mapall=tih
Locally, I have the same uids and gids everywhere, so just mapping
straight through is fine. Then there's that Ubuntu workstation that's
different, but since I'm always "tih" on it, I can just use mapall
to correct my uid and gid, and still let maproot give root access.
Here's the patch:
--- mfsmaster/exports.c~ 2014-11-27 10:18:30.000000000 +0100
+++ mfsmaster/exports.c 2014-12-23 09:51:01.000000000 +0100
@@ -229,7 +229,11 @@
if (f==NULL) {
f=e;
} else {
- if ((e->sesflags&SESFLAG_READONLY)==0 && (f->sesflags&SESFLAG_READONLY)!=0) { // prefer rw to ro
+ if ((e->toip - e->fromip) < (f->toip - f->fromip)) { // prefer more specific address match
+ f=e;
+ } else if (e->pleng > f->pleng) { // prefer more accurate path
+ f=e;
+ } else if ((e->sesflags&SESFLAG_READONLY)==0 && (f->sesflags&SESFLAG_READONLY)!=0) { // prefer rw to ro
f=e;
} else if (e->rootuid==0 && f->rootuid!=0) { // prefer root not restricted to restricted
f=e;
@@ -237,8 +241,6 @@
f=e;
} else if (e->needpassword==1 && f->needpassword==0) { // prefer lines with passwords
f=e;
- } else if (e->pleng > f->pleng) { // prefer more accurate path
- f=e;
}
}
}
-tih
--
It doesn't matter how beautiful your theory is, it doesn't matter how smart
you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman
|
|
From: Tom I. H. <ti...@ha...> - 2014-12-23 10:13:04
|
I have this Ubuntu workstation, where my uid and gid are different from what they are everywhere else. To fix it, my mfsexports.cfg includes a line like this: 1.2.3.4/32 / rw,alldirs,maproot=root,mapall=tih This works well, because I'm always "tih" on that workstation, except when I sudo to root. There's one exception, though: rmdir as the unprivileged user doesn't work. I can create directories (and they end up being owned by "tih" on the mfsmaster), but I cannot remove them. If I sudo to root on the client, I can remove the directories. Additionally, the "sudo rmdir" workaround works even if I drop the "maproot=root" option from mfsmount.cfg. With this: 1.2.3.4/32 / rw,alldirs,mapall=tih I still cannot remove directories I've created, and it still works to sudo to root to remove them. -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
|
From: Tom I. H. <ti...@ha...> - 2014-12-23 10:07:11
|
I have this Ubuntu workstation, where my uid and gid are different from
what they are everywhere else. To fix it, my mfsexports.cfg includes a
line like this:
1.2.3.4/32 / rw,alldirs,maproot=root,mapall=tih
This works well, because I'm always "tih" on that workstation, except
when I sudo to root. However, mfsmount, while doing the right thing,
tells me it's doing something else. :)
It says:
mfsmaster accepted connection with parameters: read-write,restricted_ip,map_all ; root mapped to root:root ; users mapped to root:root
Without the 'maproot=root' option (leaving just 'mapall=tih'), it's
still wrong:
mfsmaster accepted connection with parameters: read-write,restricted_ip,map_all ; root mapped to 501:dialout ; users mapped to root:root
("501:dialout" is because my user, "tih", has uid 501 on the mfsmaster,
and a gid that maps to "dialout" on the client. I frankly don't see why
it should convert the uids and gids to local names on the client,
anyway: we're mapping to something on the mfsmaster, and what might be
interesting to know is the numeric values, not what names they happen to
map to on the client.)
In both cases, it *behaves* as expected (with the maproot, I can create
files as root, without it, root will also create files as tih). It's
only the informational output that's wrong.
-tih
--
It doesn't matter how beautiful your theory is, it doesn't matter how smart
you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman
|
|
From: Krzysztof K. <krz...@mo...> - 2014-11-26 17:10:08
|
Dear MooseFS Users, Today we would like share with you a great news - we’re officially releasing the latest and gratest version of MooseFS Pro and CE along with long awaited souce code for CE edition available for download from newly designed website at http://moosefs.com <http://moosefs.com/>. Another great news is that as of today we put on our product list the MooseFS Rack - tested and preconfigured, ready to use hardware storage solution based on MooseFS Pro. For details please visit http://moosefs.com <http://moosefs.com/> Best Regards, Krzysztof Kielak Director of Operations and Customer Support Mobile: +48 601 476 440 |
|
From: Aleksander W. <ale...@mo...> - 2014-11-26 11:00:27
|
Hi. Can You send us some more details on dw...@mo...? Maybe something like: - the exact version of MooseFS - log's from system - uname -a - free -m - how many chunks are in your cluster? Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 11/26/2014 08:30 AM, John Li wrote: > Master, chunk servers always die. > It suspect because of the the RAM limited. > There's no such issue for the older version > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > > > _______________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: John Li <ver...@gm...> - 2014-11-26 07:30:54
|
Master, chunk servers always die. It suspect because of the the RAM limited. There's no such issue for the older version |
|
From: Tom I. H. <ti...@ha...> - 2014-11-25 08:09:31
|
Aleksander Wieliczko <ale...@mo...> writes: > We are in progress with writing MooseFS 2.0 documentation. > Latest manuals and guides can be downloaded from http://get.moosefs.com Not bad - but there should be something about the quorum mechanism in 2.0 PRO. (And I'd like to see that configurable, as well, so one could apply different weights to different chunk servers.) -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman |
|
From: Aleksander W. <ale...@mo...> - 2014-11-24 15:16:09
|
Hi. We are in progress with writing MooseFS 2.0 documentation. Latest manuals and guides can be downloaded from http://get.moosefs.com or directly from links: http://robo.moosefs.com/support/moosefs-installation.pdf http://robo.moosefs.com/support/moosefs-users-manual.pdf http://robo.moosefs.com/support/moosefs-upgrade.pdf Basically to restore master from metalogger just: 1. Copy changelog_ml_back.*.mfs and metadata_ml.mfs.back* from /var/lib/mfs on metalogger to /var/lib/mfs on mfsmaster server 2. Run mfsmaster with automatically restore metadata from change logs option - *mfsmaster -a* Remember to do mfsmaster /var/lib/mfs directory backup even if metadata.mfs file is broken. Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 11/24/2014 12:49 PM, 王王超飞 wrote: > Hi, > > My mfs version is moosefs-ce.2.0.40 and it is installed on debian6.0 > which is ext3 filesystem. when my master is down, how could I recover > master from a metalogger or another master backup. I can't find really > detailed information from documentation, and moosefs-ce.2.0 was > changed a lot, the documentation has not updated yet.Thank you! > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > > > _______________________________________________ > moosefs-users mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moosefs-users |
|
From: 王王超飞 <wc...@gm...> - 2014-11-24 11:49:59
|
Hi, My mfs version is moosefs-ce.2.0.40 and it is installed on debian6.0 which is ext3 filesystem. when my master is down, how could I recover master from a metalogger or another master backup. I can't find really detailed information from documentation, and moosefs-ce.2.0 was changed a lot, the documentation has not updated yet.Thank you! |
|
From: Aleksander W. <ale...@mo...> - 2014-11-19 15:14:07
|
Hi. We can only suggest switch to 2.0.x version, where mfsmaster have autorecovery option, and few more features for metadata recovery. Please visit get.moosefs.com <http://get.moosefs.com> Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 11/19/2014 04:00 PM, Bán Miklós wrote: > Hi, > > you can see below, however I could restore the metadata file in an > other computer where the mfsmetarestore version is 1.6.24. > > I copied back this restored metadata file, and it seemingly works. > > > Miklos > > > (the lock file are there because I've started now the server) > > -rw-r----- 1 mfs mfs 98 Oct 28 17:10 changelog.mfs.50 > -rw-r----- 1 mfs mfs 192 Oct 29 09:27 changelog.mfs.36 > -rw-r----- 1 mfs mfs 2443 Oct 29 14:59 changelog.mfs.31 > -rw-r----- 1 mfs mfs 1962 Oct 29 15:41 changelog.mfs.30 > -rw-r----- 1 mfs mfs 38 Oct 29 17:11 changelog.mfs.28 > -rw-r----- 1 mfs mfs 43 Oct 30 09:28 changelog.mfs.12 > -rw-r----- 1 mfs mfs 74 Oct 30 11:56 changelog.mfs.10 > -rw-r----- 1 mfs mfs 1877 Oct 30 13:59 changelog.mfs.8 > -rw-r----- 1 mfs mfs 2381 Oct 30 14:51 changelog.mfs.7 > drwxr-xr-x 40 root root 4096 Oct 31 05:30 .. > -rw-r----- 1 mfs mfs 59 Nov 1 15:07 changelog.mfs.2 > -rw-r----- 1 mfs mfs 341939585 Nov 1 15:07 metadata.mfs.1 > -rw-r----- 1 mfs mfs 58 Nov 1 15:14 changelog.mfs.1 > -rw-r----- 1 mfs mfs 0 Nov 1 15:19 .mfsmaster.lock > -rw-r--r-- 1 mfs mfs 8 Nov 1 15:21 metadata.mfs.empty > -rw-r----- 1 mfs mfs 0 Nov 2 10:51 .mfschunkserver.lock > -rw-r--r-- 1 mfs mfs 5 Nov 2 20:41 .mfscgiserv.lock > -rw-r----- 1 mfs mfs 302 Nov 17 12:56 changelog.50.mfs > -rw-r----- 1 mfs mfs 2674159 Nov 17 13:59 changelog.49.mfs > -rw-r----- 1 mfs mfs 5819636 Nov 17 14:59 changelog.48.mfs > -rw-r----- 1 mfs mfs 4432583 Nov 17 15:58 changelog.47.mfs > -rw-r----- 1 mfs mfs 3555350 Nov 17 16:44 changelog.46.mfs > -rw-r----- 1 mfs mfs 192 Nov 17 17:51 changelog.45.mfs > -rw-r----- 1 mfs mfs 37 Nov 17 18:51 changelog.44.mfs > -rw-r----- 1 mfs mfs 212465 Nov 17 19:59 changelog.43.mfs > -rw-r----- 1 mfs mfs 12752 Nov 17 20:58 changelog.42.mfs > -rw-r----- 1 mfs mfs 23802 Nov 17 21:55 changelog.41.mfs > -rw-r----- 1 mfs mfs 24822 Nov 17 22:37 changelog.40.mfs > -rw-r----- 1 mfs mfs 8209 Nov 17 23:27 changelog.39.mfs > -rw-r----- 1 mfs mfs 6007 Nov 18 00:42 changelog.38.mfs > -rw-r----- 1 mfs mfs 19229 Nov 18 01:44 changelog.37.mfs > -rw-r----- 1 mfs mfs 4731 Nov 18 02:53 changelog.36.mfs > -rw-r----- 1 mfs mfs 34702 Nov 18 03:59 changelog.35.mfs > -rw-r----- 1 mfs mfs 4624 Nov 18 04:53 changelog.34.mfs > -rw-r----- 1 mfs mfs 507 Nov 18 05:38 changelog.33.mfs > -rw-r----- 1 mfs mfs 1644994 Nov 18 06:45 changelog.32.mfs > -rw-r----- 1 mfs mfs 1762361 Nov 18 07:59 changelog.31.mfs > -rw-r----- 1 mfs mfs 817500 Nov 18 08:50 changelog.30.mfs > -rw-r----- 1 mfs mfs 2321189 Nov 18 09:59 changelog.29.mfs > -rw-r----- 1 mfs mfs 5141932 Nov 18 10:59 changelog.28.mfs > -rw-r----- 1 mfs mfs 5093724 Nov 18 11:59 changelog.27.mfs > -rw-r----- 1 mfs mfs 4204526 Nov 18 12:59 changelog.26.mfs > -rw-r----- 1 mfs mfs 4639505 Nov 18 14:00 changelog.25.mfs > -rw-r----- 1 mfs mfs 4728075 Nov 18 14:59 changelog.24.mfs > -rw-r----- 1 mfs mfs 2634351 Nov 18 15:50 changelog.23.mfs > -rw-r----- 1 mfs mfs 3714548 Nov 18 16:59 changelog.22.mfs > -rw-r----- 1 mfs mfs 2186488 Nov 18 17:59 changelog.21.mfs > -rw-r----- 1 mfs mfs 96401 Nov 18 18:34 changelog.20.mfs > -rw-r----- 1 mfs mfs 1352 Nov 18 20:00 changelog.19.mfs > -rw-r----- 1 mfs mfs 44548 Nov 18 21:00 changelog.18.mfs > -rw-r----- 1 mfs mfs 46509 Nov 18 22:00 changelog.17.mfs > -rw-r----- 1 mfs mfs 35155 Nov 18 22:59 changelog.16.mfs > -rw-r----- 1 mfs mfs 24683 Nov 18 23:59 changelog.15.mfs > -rw-r----- 1 mfs mfs 7799 Nov 19 00:45 changelog.14.mfs > -rw-r----- 1 mfs mfs 236 Nov 19 01:45 changelog.13.mfs > -rw-r----- 1 mfs mfs 9208 Nov 19 02:55 changelog.12.mfs > -rw-r----- 1 mfs mfs 4059 Nov 19 03:35 changelog.11.mfs > -rw-r----- 1 mfs mfs 1513746 Nov 19 06:54 changelog.8.mfs > -rw-r----- 1 mfs mfs 4712 Nov 19 07:49 changelog.7.mfs > -rw-r----- 1 mfs mfs 146156 Nov 19 08:50 changelog.6.mfs > -rw-r----- 1 mfs mfs 410044 Nov 19 09:37 changelog.5.mfs > -rw-r----- 1 mfs mfs 2659 Nov 19 11:00 changelog.4.mfs > -rw-r----- 1 mfs mfs 76513 Nov 19 11:59 changelog.3.mfs > -rw-r----- 1 mfs mfs 43923 Nov 19 13:00 changelog.2.mfs > -rw-r----- 1 mfs mfs 347448659 Nov 19 13:00 metadata.mfs.back.1 > -rw-r----- 1 mfs mfs 211698 Nov 19 13:59 changelog.1.mfs > -rwxr-xr-x 1 mfs mfs 915016 Nov 19 14:00 csstats.mfs > -rw-r----- 1 mfs mfs 4114 Nov 19 14:00 sessions.mfs > -rwxr-xr-x 1 mfs mfs 762516 Nov 19 14:00 stats.mfs > -rw-r----- 1 mfs mfs 347481307 Nov 19 14:00 metadata.mfs.back > -rw-r----- 1 mfs mfs 48291 Nov 19 14:31 changelog.0.mfs > > > > On Wed, 19 Nov 2014 15:36:25 +0100 > Aleksander Wieliczko <ale...@mo...> wrote: > >> Hi. >> Can you send us the result of ls command ? >> >> ls -alrt /var/lib/mfs >> >> Best regards >> Aleksander Wieliczko >> Technical Support Engineer >> MooseFS.com <moosefs.com> >> On 11/19/2014 03:19 PM, Bán Miklós wrote: >>> Hi, >>> >>> I have tried to restore the metadata file after a power failure with >>> this command: >>> >>> mfsmetarestore -a >>> >>> I've got this result: >>> >>> loading objects (files,directories,etc.) ... ok >>> loading names ... ok >>> loading deletion timestamps ... ok >>> loading chunks data ... ok >>> checking filesystem consistency ... ok >>> connecting files and chunks ... ok >>> Floating point exception >>> >>> >>> No metadata file restored. >>> >>> We are using mfs 1.6.27-5 >>> >>> >>> Are there any solution? >>> >>> >>> Thanks, Miklos >>> >>> >>> > > |
|
From: Bán M. <ba...@vo...> - 2014-11-19 15:00:28
|
Hi, you can see below, however I could restore the metadata file in an other computer where the mfsmetarestore version is 1.6.24. I copied back this restored metadata file, and it seemingly works. Miklos (the lock file are there because I've started now the server) -rw-r----- 1 mfs mfs 98 Oct 28 17:10 changelog.mfs.50 -rw-r----- 1 mfs mfs 192 Oct 29 09:27 changelog.mfs.36 -rw-r----- 1 mfs mfs 2443 Oct 29 14:59 changelog.mfs.31 -rw-r----- 1 mfs mfs 1962 Oct 29 15:41 changelog.mfs.30 -rw-r----- 1 mfs mfs 38 Oct 29 17:11 changelog.mfs.28 -rw-r----- 1 mfs mfs 43 Oct 30 09:28 changelog.mfs.12 -rw-r----- 1 mfs mfs 74 Oct 30 11:56 changelog.mfs.10 -rw-r----- 1 mfs mfs 1877 Oct 30 13:59 changelog.mfs.8 -rw-r----- 1 mfs mfs 2381 Oct 30 14:51 changelog.mfs.7 drwxr-xr-x 40 root root 4096 Oct 31 05:30 .. -rw-r----- 1 mfs mfs 59 Nov 1 15:07 changelog.mfs.2 -rw-r----- 1 mfs mfs 341939585 Nov 1 15:07 metadata.mfs.1 -rw-r----- 1 mfs mfs 58 Nov 1 15:14 changelog.mfs.1 -rw-r----- 1 mfs mfs 0 Nov 1 15:19 .mfsmaster.lock -rw-r--r-- 1 mfs mfs 8 Nov 1 15:21 metadata.mfs.empty -rw-r----- 1 mfs mfs 0 Nov 2 10:51 .mfschunkserver.lock -rw-r--r-- 1 mfs mfs 5 Nov 2 20:41 .mfscgiserv.lock -rw-r----- 1 mfs mfs 302 Nov 17 12:56 changelog.50.mfs -rw-r----- 1 mfs mfs 2674159 Nov 17 13:59 changelog.49.mfs -rw-r----- 1 mfs mfs 5819636 Nov 17 14:59 changelog.48.mfs -rw-r----- 1 mfs mfs 4432583 Nov 17 15:58 changelog.47.mfs -rw-r----- 1 mfs mfs 3555350 Nov 17 16:44 changelog.46.mfs -rw-r----- 1 mfs mfs 192 Nov 17 17:51 changelog.45.mfs -rw-r----- 1 mfs mfs 37 Nov 17 18:51 changelog.44.mfs -rw-r----- 1 mfs mfs 212465 Nov 17 19:59 changelog.43.mfs -rw-r----- 1 mfs mfs 12752 Nov 17 20:58 changelog.42.mfs -rw-r----- 1 mfs mfs 23802 Nov 17 21:55 changelog.41.mfs -rw-r----- 1 mfs mfs 24822 Nov 17 22:37 changelog.40.mfs -rw-r----- 1 mfs mfs 8209 Nov 17 23:27 changelog.39.mfs -rw-r----- 1 mfs mfs 6007 Nov 18 00:42 changelog.38.mfs -rw-r----- 1 mfs mfs 19229 Nov 18 01:44 changelog.37.mfs -rw-r----- 1 mfs mfs 4731 Nov 18 02:53 changelog.36.mfs -rw-r----- 1 mfs mfs 34702 Nov 18 03:59 changelog.35.mfs -rw-r----- 1 mfs mfs 4624 Nov 18 04:53 changelog.34.mfs -rw-r----- 1 mfs mfs 507 Nov 18 05:38 changelog.33.mfs -rw-r----- 1 mfs mfs 1644994 Nov 18 06:45 changelog.32.mfs -rw-r----- 1 mfs mfs 1762361 Nov 18 07:59 changelog.31.mfs -rw-r----- 1 mfs mfs 817500 Nov 18 08:50 changelog.30.mfs -rw-r----- 1 mfs mfs 2321189 Nov 18 09:59 changelog.29.mfs -rw-r----- 1 mfs mfs 5141932 Nov 18 10:59 changelog.28.mfs -rw-r----- 1 mfs mfs 5093724 Nov 18 11:59 changelog.27.mfs -rw-r----- 1 mfs mfs 4204526 Nov 18 12:59 changelog.26.mfs -rw-r----- 1 mfs mfs 4639505 Nov 18 14:00 changelog.25.mfs -rw-r----- 1 mfs mfs 4728075 Nov 18 14:59 changelog.24.mfs -rw-r----- 1 mfs mfs 2634351 Nov 18 15:50 changelog.23.mfs -rw-r----- 1 mfs mfs 3714548 Nov 18 16:59 changelog.22.mfs -rw-r----- 1 mfs mfs 2186488 Nov 18 17:59 changelog.21.mfs -rw-r----- 1 mfs mfs 96401 Nov 18 18:34 changelog.20.mfs -rw-r----- 1 mfs mfs 1352 Nov 18 20:00 changelog.19.mfs -rw-r----- 1 mfs mfs 44548 Nov 18 21:00 changelog.18.mfs -rw-r----- 1 mfs mfs 46509 Nov 18 22:00 changelog.17.mfs -rw-r----- 1 mfs mfs 35155 Nov 18 22:59 changelog.16.mfs -rw-r----- 1 mfs mfs 24683 Nov 18 23:59 changelog.15.mfs -rw-r----- 1 mfs mfs 7799 Nov 19 00:45 changelog.14.mfs -rw-r----- 1 mfs mfs 236 Nov 19 01:45 changelog.13.mfs -rw-r----- 1 mfs mfs 9208 Nov 19 02:55 changelog.12.mfs -rw-r----- 1 mfs mfs 4059 Nov 19 03:35 changelog.11.mfs -rw-r----- 1 mfs mfs 1513746 Nov 19 06:54 changelog.8.mfs -rw-r----- 1 mfs mfs 4712 Nov 19 07:49 changelog.7.mfs -rw-r----- 1 mfs mfs 146156 Nov 19 08:50 changelog.6.mfs -rw-r----- 1 mfs mfs 410044 Nov 19 09:37 changelog.5.mfs -rw-r----- 1 mfs mfs 2659 Nov 19 11:00 changelog.4.mfs -rw-r----- 1 mfs mfs 76513 Nov 19 11:59 changelog.3.mfs -rw-r----- 1 mfs mfs 43923 Nov 19 13:00 changelog.2.mfs -rw-r----- 1 mfs mfs 347448659 Nov 19 13:00 metadata.mfs.back.1 -rw-r----- 1 mfs mfs 211698 Nov 19 13:59 changelog.1.mfs -rwxr-xr-x 1 mfs mfs 915016 Nov 19 14:00 csstats.mfs -rw-r----- 1 mfs mfs 4114 Nov 19 14:00 sessions.mfs -rwxr-xr-x 1 mfs mfs 762516 Nov 19 14:00 stats.mfs -rw-r----- 1 mfs mfs 347481307 Nov 19 14:00 metadata.mfs.back -rw-r----- 1 mfs mfs 48291 Nov 19 14:31 changelog.0.mfs On Wed, 19 Nov 2014 15:36:25 +0100 Aleksander Wieliczko <ale...@mo...> wrote: > Hi. > Can you send us the result of ls command ? > > ls -alrt /var/lib/mfs > > Best regards > Aleksander Wieliczko > Technical Support Engineer > MooseFS.com <moosefs.com> > On 11/19/2014 03:19 PM, Bán Miklós wrote: > > Hi, > > > > I have tried to restore the metadata file after a power failure with > > this command: > > > > mfsmetarestore -a > > > > I've got this result: > > > > loading objects (files,directories,etc.) ... ok > > loading names ... ok > > loading deletion timestamps ... ok > > loading chunks data ... ok > > checking filesystem consistency ... ok > > connecting files and chunks ... ok > > Floating point exception > > > > > > No metadata file restored. > > > > We are using mfs 1.6.27-5 > > > > > > Are there any solution? > > > > > > Thanks, Miklos > > > > > > > -- Miklós Bán MTA-DE "Lendület" Behavioural Ecology Research Group Department of Evolutionary Zoology, University of Debrecen H-4010 Debrecen, Egyetem tér 1. Phone: +36 52 512-900 ext. 62356 http://zoology.unideb.hu/?m=Miklós_Bán ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
From: Aleksander W. <ale...@mo...> - 2014-11-19 14:36:37
|
Hi. Can you send us the result of ls command ? ls -alrt /var/lib/mfs Best regards Aleksander Wieliczko Technical Support Engineer MooseFS.com <moosefs.com> On 11/19/2014 03:19 PM, Bán Miklós wrote: > Hi, > > I have tried to restore the metadata file after a power failure with > this command: > > mfsmetarestore -a > > I've got this result: > > loading objects (files,directories,etc.) ... ok > loading names ... ok > loading deletion timestamps ... ok > loading chunks data ... ok > checking filesystem consistency ... ok > connecting files and chunks ... ok > Floating point exception > > > No metadata file restored. > > We are using mfs 1.6.27-5 > > > Are there any solution? > > > Thanks, Miklos > > > |
84 messages has been excluded from this view by a project administrator.
