New install: mogstored dying, and mogtool problems

Greg Connor gconnor at nekodojo.org
Wed Apr 30 15:49:53 UTC 2008


Hello... I'm new to mogilefs and the list, so please feel free to 
redirect me to other resources that may be out there which I haven't 
found yet.

I just now finished setting up MogileFS for the first time.  I have run 
into some problems that hopefully others have seen before and can help 
me with.

First, I had to make some changes to the code (even after getting the 
current subversion trunk) which blocked me from running make or starting 
the daemons for the first time.  They seemed like they had been there a 
while but also seemed pretty easy to fix.  I'll post diffs if folks are 
interested but I suspect almost everyone has fixed these on their own or 
the cluster wouldn't be operational.  I'm only mentioning it here in 
case this indicates *I've* done something wrong.  These were:
MogileFS/Worker.pm
   #warn "proc ${self}[$$] read: [$out]\n";
   # fails because @self doesn't exist (should be $self-> ?)
   warn "proc \${self}[\$\$] read: [$out]\n";
Gearman/Client/Async/Connection.pm
   #socket my $sock, PF_INET, SOCK_STREAM, IPPROTO_TCP;
   #missing parens around "my"
   # changed to
   my $sock ; socket $sock, PF_INET, SOCK_STREAM, IPPROTO_TCP;
...and there may be one other change I'm now forgetting.

I'm now using mogtool to store contents of an entire directory, and 
encountering some problems. (Using a 90G directory to start but 
eventually this will be 1.5T directories).

First problem was that when I first used mogtool to start injecting 
files, I got a lot of errors (now scrolled off my screen, but it was 
something like "could not put file, unknown_fileid") and I observed that 
mogstored had stopped running on all 16 nodes.  After mogtool was 
killed, fsck reported that there were a lot of files, but listing the 
domain showed 0 files.  I could not figure out how to hunt down and 
delete the chunks that mogtool had already uploaded, since the target 
(only) domain seemed to be empty.  Since I could not figure out how to 
delete the files cleanly, I opted to drop database mogilefs, nuke dev*/0 
and restart everything from scratch.

On the second attempt, mogstored now stays up, and the upload completed 
quickly, but after a 52 minute upload mogtool then proceeded to checksum 
everything and got stuck on checksumming the same 6 blocks over and 
over, for 18 more hours before I stopped it.  It was saying something 
like "retrying checksum for chunks: blah... md5sum mismatch" over and 
over.  I'm not sure what the correct behavior here should be, but if 
both copies of a chunk have failed checksum, and the original file 
(stream) is no longer available, at some point it should probably 
declare failure and stop fetching the bad chunks repeatedly.

My first priority here would be to figure out why mogstored died and 
keep it from dying.  Has this happened before/frequently?  Is it common 
practice to put a wrapper or sentinel on mogstored to start it when it 
fails?  Is there a log file where mogstored shows any warn or die 
messages?  (I used an /etc/init.d/mogstored start script found in the 
archives of this list, so perhaps I just need to replace the >/dev/null 
in that script with an actual file)

My second priority would be to figure out how to recover from a failed 
mogtool injection.  I'm pretty sure files exist in the tracker, 
definitely they exist on nodes, but if mogtool list domain doesn't show 
them, how can I find and delete them?  (I probably will try the 
MogileFS::Client direct interface next).  If I ask mogtool to store the 
same ID again, also using --bigfile, will it overwrite the chunks it 
stored the first time or will I need to invent something to find 
orphaned bigfile chunks and remove them after a certain time?

Thinking ahead to the fix, what's the correct/desired behavior in cases 
where a bigfile fails to inject... would it be fairly easy to make 
mogtool aware of the incomplete bigfile and its chunks (possibly under a 
different master fileid?) so future invocations of mogtool can delete 
them as expected?  In the case where we have put the chunks and fetching 
them back gives us a bad checksum, what's the proper behavior there? 
Would it be feasible to make the spawned child process wait a short time 
and then fetch its own chunk back, so that it has a chance to put the 
data up again if there is a mismatch?  I'm willing to spend some extra 
memory to have threads wait around and checksum before freeing the memory.

At this point I'm not sure if I'm doing something wrong or if my 
experience is expected/typical, so any feedback (even if it's not an 
answer/suggestion) would be helpful.  Have people used mogtool as part 
of a production system for storing huge files?  Is it more common for 
people to implement their own chunking/splitting?

Thanks for any feedback.
gregc


More information about the mogilefs mailing list