diff --git a/src/kernel/inode.c b/src/kernel/inode.c index e6b36e66df8..27b78588ff1 100644 --- a/src/kernel/inode.c +++ b/src/kernel/inode.c @@ -486,7 +486,7 @@ int ceph_handle_cap_trunc(struct inode *inode, struct ceph_mds_file_caps *trunc, dout(10, "handle_cap_trunc inode %p ci %p mds%d seq %d\n", inode, ci, mds, seq); spin_lock(&inode->i_lock); - dout(10, "size %lld -> %llu\n", inode->i_size, size); + dout(10, "trunc size %lld -> %llu\n", inode->i_size, size); inode->i_size = size; spin_unlock(&inode->i_lock); diff --git a/web/source.body b/web/source.body index fe847e02289..a2424b15fd7 100644 --- a/web/source.body +++ b/web/source.body @@ -6,7 +6,7 @@

The Ceph project is always looking for more participants. If you are interested in using Ceph, or contributing to its development, please join our mailing list and drop us a line. -

Checking out

+

Checking out the source

You can check out a working copy (actually, clone the repository) with
@@ -27,16 +27,16 @@ git pull
 		
There are a range of binary targets, mostly for ease of development and testing:
    +
  • cmon -- monitor
  • +
  • cosd -- OSD storage daemon
  • +
  • cmds -- MDS metadata server
  • +
  • cfuse -- client, mountable via FUSE
  • +
  • csyn -- client sythetic workload generator
  • +
  • cmonctl -- control tool
  • +

  • fakesyn -- places all logical elements (MDS, client, etc.) in a single binary, with synchronous message delivery (for easy debugging!). Includes synthetic workload generation.
  • fakefuse -- same as fakesyn, but mounts a single client via FUSE.
  • -
  • newsyn -- starts up all logical elements using MPI. As with fakesyn, it includes synthetic workload generation.
  • -
  • cosd -- standalone OSD
  • -
  • cmon -- standalone monitor
  • -
  • cmds -- standalone MDS
  • -
  • cfuse -- standalone client, mountable via FUSE
- - For most development, fakesyn, fakefuse, and newsyn are sufficient.

Runtime Environment

@@ -47,11 +47,12 @@ git pull
  • Checkout, change into the ceph/src directory, and build. E.g.,
     git clone git://ceph.newdream.net/ceph.git
    -cd ceph/src
    -make mpi=no fuse=no
    +cd ceph
    +./autogen.sh
    +./configure   # of CXXFLAGS="-g" ./configure to disable optimizations (for debugging)
    +cd src
    +make
     
    -(You can omit the mpi=no or fuse=no if you happen to have those installed.) -
  • Create a log/ dir for various runtime stats.
    @@ -76,22 +77,6 @@ done
     		
  • -

    Running fakesyn -- everything one process

    -
    - A quick example, assuming you've set up "fake" EBOFS devices as above: -
    -make fakesyn && ./fakesyn --mkfs --debug_ms 1 --debug_client 3 --syn rw 1 100000
    -# where those options mean:
    -#	--mkfs               # start with a fresh file system
    -#	--debug_ms 1         # show message delivery
    -#	--debug_client 3     # show limited client stuff
    -#	--syn rw 1 100000    # write 1MB to a file in 100,000 byte chunks, then read it back
    -
    - One the synthetic workload finishes, the synthetic client unmounts, and the whole system shuts down. - - The full set of command line arguments can be found in config.cc. -
    -

    Starting up a full "cluster" on a single host

    You can start up a the full cluster of daemons on a single host. Assuming you've created a set of individual files for each OSD's block device (the second option of #3 above), there is a start.sh and stop.sh script that will start up on port 12345. @@ -162,52 +147,22 @@ mount -t ceph 1.2.3.4:/ mnt # 1.2.3.4 is host
    -

    Running on multiple nodes

    +

    Running fakesyn -- everything one process

    - If you're ready to start things up on multiple nodes (or even just multiple processes on the same node), newsyn is the easiest way to get things launched. It uses MPI to start up all the processes. Assuming you have MPICH2 (or similar) installed, + A quick example, assuming you've set up "fake" EBOFS devices as above:
    -mpd &           # for a single host
    -mpiboot -n 10   # for multiple hosts (see MPICH docs)
    -make newsyn && mpiexec -l -n 10 ./newsyn --mkfs --nummds 1 --numosd 6 --numclient 20 --syn writefile 100 16384
    +make fakesyn && ./fakesyn --mkfs --debug_ms 1 --debug_client 3 --syn rw 1 100000
    +# where those options mean:
    +#	--mkfs               # start with a fresh file system
    +#	--debug_ms 1         # show message delivery
    +#	--debug_client 3     # show limited client stuff
    +#	--syn rw 1 100000    # write 1MB to a file in 100,000 byte chunks, then read it back
     
    - You will probably want to make dev/osd.all a symlink to some block device that exists on every node you're starting an OSD on. Otherwise, you'll need a symlink (for "block device" file) for each osd. + One the synthetic workload finishes, the synthetic client unmounts, and the whole system shuts down. - If you want to mount a distributed FS (instead of generating a synthetic workload), try -
    -make newsyn && mpiexec -l -n 10 ./newsyn --mkfs --nummds 2 --numosd 6 --numclient 0     # 0 clients, just mds and osds
    -# in another terminal,
    -mkdir mnt
    -make cfuse && ./cfuse mnt
    -# and in yet another terminal,
    -ls mnt 
    -touch mnt/asdf   # etc
    -
    - Currently, when the last client (cfuse instance, in this case) shuts down, the whole thing will shut down. Assuming things shut down cleanly, you should be able to start things up again without the --mkfs flag and recover the prior file system state. + The full set of command line arguments can be found in config.cc.
    -

    Structure

    -
    - Here's a crude table diagram that shows how the major (user space) pieces fit together. Ingore the MDS bits; that's mostly wrong. - - FIXME: this links to the old Subversion repository. - - - - - - - - - - - - - - - -
    Application
    kernel
    Application FUSE glue
    Client MDS
    Filer ObjectCacher MDLogMDStore
    Objecter
    (message layer)
    OSD
    ObjectStore
    EBOFS FakeStore
    BlockDevice
    Kernel POSIX interface
    Key: Network Entity Lib/module Abstract interface Kernel
    - -