Le 23/11/2011 16:13, Sage Weil a écrit :
On Wed, 23 Nov 2011, Alexandre Oliva wrote:
On Nov 22, 2011, Sage Weil<s...@newdream.net> wrote:
On Tue, 22 Nov 2011, Christian Brunner wrote:
- compression: I'm using lzo compression right now, as my CPUs in the
OSD nodes where idle most of the time and it is improving throughput
quite a bit.
The caveat here is that there is a corner case with inline extents and the
clone ioctl that isn't implemented.
What happens when you trigger that case? Crash or corruption?
I ask because I've been running with zlib compression, and I haven't
noticed any problems along these lines, though I haven't got to a point
in which I'm doing more than rsyncing whole trees into the filesystem
yet.
Took another look at this. The ioctl will return EINVAL from
fs/btrfs/ioctl.c:2416:
if (comp&& (skip || trim)) {
ret = -EINVAL;
btrfs_end_transaction(trans, root);
goto out;
}
If os/FileStore.cc::_do_clone_range() sees EINVAL, it falls back to doing
a copy. That may not be ideal in some cases, but at least it's
"correct". For example,
0-8192 compressed inline
8192-100MB normal extent
and we clone 4k - 100MB, and get EINVAL, we ideally wouldn't fall back to
naively copying 100MB. For RBD, those blocks are 4MB by default, so it's
not a big deal.
So you should be okay here.
sage
So, right now, in recent ceph versions (Using 0.44.1 for the moment),
does using compress=lzo in btrfs IS considered stable ?
Cheers ,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : yann.dup...@univ-nantes.fr
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
