the replacation speed is very slow

[hsq...@gmail.com]

hello, I am the new user of xfs, and I set the replication-factor to 2 and set replication-policy to WaRa,

but the replication speed is very very very slow(less then 300 KByte), how can I solve the issue ? thank you.

"xtfsutil --set-drp --replication-policy WaRa --replication-factor 2"

[Michael Berlin]

Hi,

I assume you mean the policy "WaR1" and not "WaRa"? "WaRa" is no longer
a valid policy name since 1.3.1.

The slow writes may be caused by unaligned and/or small writes.
Currently, the XtreemFS replication always updates the whole chunk.
Since the default chunk size (also referred as stripe size or object
size) is 128 kB, make sure your accessing application writes buffer to
the file system which are aligned to the chunk boundaries and have the
same size as the chunk.

Here are some recommendations to mitigate the problems:

1. Use asynchronous writes.

Keep in mind that your application accesses the file system
synchronously: It won't write the next buffer until the previous write
has been acknowledged by XtreemFS. This results in a slow throughput
over high latency links. To mitigate this, you can enable the
asynchronous writes in the client: --enable-async-writes This will
result in a pipeling of write requests and the maximum network
throughput should be reached.

2. Examine the access pattern of your application and adjust the chunk
size accordingly.

Run the client with "-d DEBUG -f" in the foreground to find out the size
of the application's write buffer. Now reduce the default chunk size for
the volume: xtfsutil --set-dsp -s 32 -w 1 <mount point> (This command
would set the chunk size to 32 kB). I recently tested the Firefox
download manager and had to find out that it writes 32 kB buffers.
Therefore, I also reduced the chunk size in my tests. However, higher
chunk sizes are better as they reduce the footprint on the OSD. Each
chunk is versioned and the memory and file system load decreases if
there less chunks to be versioned.

3. Try the chunk/object cache in the current developer version.

The current Git master branch contains a feature "object cache": writes
are kept back locally until the file is closed, flushed or the cache is
full. This will help a lot in case of small writes: Writes are collected
locally first and then transferred as whole chunks to the OSDs. It can
be enabled by setting a value > 0 for the option --object-cache-size.

Best regards,
Michael

> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "XtreemFS" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to xtreemfs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>