RE: Adding compression support for bluestore.

[Allen Samuels <Allen.Samuels@sandisk.com>]

As described earlier, we can easily afford the cost of setting min_alloc_size to  4KB. I don't see any advantage in handling the larger allocation sizes -- only disadvantages.

Allen Samuels
Software Architect, Fellow, Systems and Software Solutions 

2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samuels@SanDisk.com


> -----Original Message-----
> From: Sage Weil [mailto:sage@newdream.net]
> Sent: Wednesday, March 16, 2016 2:15 PM
> To: Allen Samuels <Allen.Samuels@sandisk.com>
> Cc: Igor Fedotov <ifedotov@mirantis.com>; ceph-devel <ceph-
> devel@vger.kernel.org>
> Subject: RE: Adding compression support for bluestore.
> 
> On Wed, 16 Mar 2016, Allen Samuels wrote:
> > > A potential issue with using WAL for compressed block overwrites is
> > > significant WAL data volume increase. IIUC currently WAL record can
> > > have up to 2*bluestore_min_alloc_size (i.e. 128K) client data per
> > > single write request
> > > - overlapped head and tail.
> > > In case of compressed blocks this will be up to
> > > 2*bluestore_max_compressed_block ( i.e. 8Mb ) as you can't simply
> > > overwrite fully overlapped extents - one should operate compression
> > > blocks now...
> > >
> > > Seems attractive otherwise...
> >
> > This is one of the fundamental tradeoffs with compression. When your
> compression block size exceeds the minimum I/O size you either have to
> consume time (RMW + uncompress/recompress) or you have to consume
> space (overlapping extents). Sage's current code essentially starts out by
> consuming space and then assumes in the background that he'll consume
> time to recover the space.
> > Of course if you set the compression block size equal to or smaller than the
> minimum I/O size you can avoid these problems -- but you create others
> (including poor compression, needing to track very small chunks of space,
> etc.) and nobody seriously believes that this is a viable alternative.
> 
> My inclination would be to set min_alloc_size to something smallish (if not
> 64KB, then 32KB perhaps) and the compression_block to something also
> reasonable (256KB or 512KB at most).  That means you lose some of the
> savings (on average, 1/2 of min_alloc_size) which is more significant if
> compression_block is not >> min_alloc_size, but it avoids the expensive
> r/m/w cases and big read + decompress for a small read request...
> 
> sage