That is an interesting observation. Unfortunately, it probably is a third-order optimization. (You'll be saving 4 or 8 bytes per ONODE, not much to write home about). > -----Original Message----- > From: Chris Dunlop [mailto:chris@xxxxxxxxxxxx] > Sent: Monday, April 04, 2016 8:51 AM > To: Sage Weil <sage@xxxxxxxxxxxx> > Cc: Marcel Lauhoff <lauhoff@xxxxxxxxxxxx>; Gregory Farnum > <gfarnum@xxxxxxxxxx>; Allen Samuels <Allen.Samuels@xxxxxxxxxxx>; Igor > Fedotov <ifedotov@xxxxxxxxxxxx>; ceph-devel <ceph- > devel@xxxxxxxxxxxxxxx> > Subject: Re: Adding compression/checksum support for bluestore. > > On Tue, Apr 05, 2016 at 01:33:30AM +1000, Chris Dunlop wrote: > > On Sun, Apr 03, 2016 at 09:27:22AM -0400, Sage Weil wrote: > > > In any case, it seems like the way to proceed is to have a variable > > > length checksum_block_size, since we need that anyway for other > > > reasons (e.g., balancing minimum read size and read amplification > > > for small IOs vs metadata overhead). > > > > Or a selectable checksum routine (like ZFS)? If going this way, the > > checksum_type would determine the checksum_block_size. > > ...and, also like ZFS, a cryptographic strength checksum could tie in with > Marcel's deduplication effort. > > Chris -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
