On Thu, 5 Apr 2012, Yann Dupont wrote:
> Le 23/11/2011 16:13, Sage Weil a écrit :
> > On Wed, 23 Nov 2011, Alexandre Oliva wrote:
> > > On Nov 22, 2011, Sage Weil<sage@xxxxxxxxxxxx> 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 ?
Yes, it's safe. We fall back to a manual copy if we see EINVAL from the
ioctl.
sage
