New to MogileFS have a few questions

[David Mcanulty]

Wow, thanks for the quick response! Some of your answers will REALLY
help me out. I have a follow up question or two :D

>> 1. How come i have to do a "mogadm fsck reset" before a "mogadm fsck
>> start" in order to repair a file i corrupted/deleted? Is there any
>> downside to this?
>
> The fsck process starts at the beginning and runs to the end.  The
> reset forces it to start back over at the beginning.  (This is so that
> you can analyze the results of the fsck after it finishes going
> through.)
>
> 99% sure about this one anyway, not TOO familiar with the fsck code nowadays.

I should have listed additional details here, sorry. Here is what I'm
referring to:

[root at sdxen03 000]# ls
0000000034.fid  0000000037.fid  0000000038.fid

[root at sdxen02 000]# ls
0000000034.fid  0000000037.fid  0000000038.fid

Now i remove a file:
[root at sdxen02 000]# rm -f 0000000038.fid

and i run a normal fsck
[root at sdxen03 000]# mogadm fsck status

    Running: No
     Status: 38 / 38 (100.00%)
       Time: 0s (0 fids/s; 0s remain)
 Check Type: Normal (check policy + files)

[root at sdxen03 000]# mogadm fsck start

[root at sdxen03 000]# mogadm fsck status

    Running: No
     Status: 38 / 38 (100.00%)
       Time: 0s (0 fids/s; 0s remain)
 Check Type: Normal (check policy + files)

and the file is still gone:
[root at sdxen02 000]# ls 0000000038.fid
ls: cannot access 0000000038.fid: No such file or directory

Now i run a fsck reset and fsck start again
[root at sdxen03 000]# mogadm fsck reset && mogadm fsck start

and i get my file back:
[root at rt-dev 000]# ls 0000000038.fid
0000000038.fid

So I'm planning to just always do resets first, is this safe/cool?

>> 2. If a disk fails, when i replace it, is MogileFS smart enough to
>> finish reaping it before putting that node back into production?
>
> Not automatically, no.  It doesn't know if a disk is down or dead.
> When a disk dies, you do two things:
>
> 1) bring up a new disk as a NEW device ID (very important! do not
> reuse device IDs!)
> 2) mark the old device as "dead"
>
> This will tell MogileFS to start removing files from the old one, and
> the replicator will then pick up on this and start replicating them
> out according to the policy.

Thanks, i would have done this completely wrong!

>> 3. The content length checking works for files that are corrupted with
>> wrong length. Are there any patches that apply MD5 capability to the
>> database/fsck?
>
> You can choose the fsck level, and the higher levels will do MD5 (or
> SHA1, I forget) on the files on all devices and ensure that they
> match.  Not too sure what happens if they don't.  :-)

I dug through the code tree and i can't find anything about additional
fsck options other then --policy-only.

>> 4. Which version should i use for production on a Fedora 8 server? The
>> SVN, the stable or the RPMs?
>
> Depends on what functionality you need.  I always suggest the SVN
> version, MogileFS has been fairly stable for a long time, it doesn't
> get tons of new functionality or things that will break it.  But if
> you feel safer, use the RPMs.
>
> Hachi or Alan can correct me if I'm wrong, but I believe that Six
> Apart is using the SVN version (or some revision that is non-packaged)
> on their production stacks.
>
>> 5. I've had "weird things" (sorry didn't document them) happen when
>> I've used host-names in the configuration files. Should i stick to IPs
>> instead?
>
> I've always used IPs.  If nothing else, it reduces dependence on DNS
> which is historically flaky in my experience.  (I don't care how good
> of a stack you have, DNS always seems to fart.)
>
>> 6. If i roll MogileFS out to 3 servers each with 3 hard drives, and
>> set the class to 3 copies, will MogileFS put all 3 copies on one
>> server, or one copy on each server?
>
> Yep.  Well, it depends on the replication policy, but the typical
> minimum replica count ones are all based on hosts.
>
> Thanks for your interest in MogileFS.  Feel free to ask any questions
> you might have, or run your setup/configuration by the list.  We're
> generally pretty helpful and don't often bite (and if we do, we have
> our shots).  :-)
>
>
> --
> Mark Smith / xb95
> smitty at gmail.com
>