Read & Append Files in MogileFS

Brad Fitzpatrick brad at danga.com
Mon Jun 25 20:52:00 UTC 2007


There's the way this should work, then the way you could hackily do it
today.

The way it should work is:

  -- you have existing file "foo", with FID #100, replicated to, say,
     3 places.

  -- you request via the protocol you'd like to edit "foo".  the
     server then breaks off one of the 3 replicas of FID #100,
     forgetting about it for FID #100, allocates FID #101, and
     gives you that URL to work with for as long as you'd like
     (possible mogilefsd renames the file first, so the URL has
      101.fid instead of 100.fid in the URL, but that doesn't
      matter)

  -- you do your DAV/otherwise edits to that URL,

  -- when you're done, you tell the server with create_close, as
     normal, as if you'd just written the whole file out, and
     the normal "'foo' now means file #101, not #100" logic
     kicks in, where #101 is replicated around, and #100 is
     cleaned up.

This way, nobody sees an inconsistent view.

Keep in mind, though, the server's still going to copy all this around
everywhere everytime you append, so it's not an answer for huge log files.

And race conditions between competing clients doing edits is unchanged
from current behavior:  last client to close blows away all previous
edits.  So locking is still up to you... Mogile won't atomically order
your appends or anything.

How you could hackily do this today:

   -- delete a mapping in file_on table
   -- clear memcache key (if using memcache with mogilefds)
   -- edit that file,
   -- switch file_on mapping/memcache to just your new location,
   -- delete others,
   -- schedule a fsck to fix.

We could even add protocol commands to do the above steps, but once we've
got that, it's pretty much a "edit_start" command, which is what you
really want.

I'm not sure what your application is, though, and if adding support for
this wouldn't just tempt people to do things in a wrong/inefficient way.

Can you explain more what you'd want to use this for?

- Brad


On Mon, 25 Jun 2007, Dan wrote:

> In an application that needs to read files and append to/change existing files in MogileFS, what is the recommended strategy?
>
> The client API only permits creation of a new file and writing to it from the start. Reading the whole file into memory is not viable and fetching the whole file back to local disk storage, editing it, then sending the whole file back to MogileFS is not elegant.
>
> If there is no existing solution, is it viable to extend the TIEHANDLE interface to support seeks and writes? I'd be comfortable with implementing the needed elements with the appropriate WebDAV requests (with byte ranges) going to the backends, but I don't know it the architecture of MogileFS would support marking the files replicas out of date and bringing them back into consistency.
>
> Any pointers would be appretiated.
>
> Regards,
>
> Dan


More information about the mogilefs mailing list