From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1586397616312721479==" MIME-Version: 1.0 From: Walker, Benjamin Subject: Re: [SPDK] Removing bs_dev Date: Wed, 25 Jul 2018 17:26:37 +0000 Message-ID: <5a321e4a3da6a6df584a2f6cdd32ba262ebda45a.camel@intel.com> In-Reply-To: 122B872DCF83AB4DB816E25A2C1AD08D8BB4A3BD@IRSMSX102.ger.corp.intel.com List-ID: To: spdk@lists.01.org --===============1586397616312721479== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, 2018-07-25 at 04:44 +0000, Szwed, Maciej wrote: > Hi, > I was examining possibility of removing bs_dev layer from blobstore. As t= his > would simplify code for basic blob/lvol usage, in case of snapshots and c= lones > it would require whole new approach. Currently bs_dev layer is a basic > mechanism for snapshots and clones interactions. I was thinking about some > other ways we could build that relations w/o bs_dev, but I couldn=E2=80= =99t find any > good mechanism which would be simpler (or at least less complicated) than= the > current one. Therefore I don=E2=80=99t think that removing bs_dev is a go= od idea. If > somebody have different thoughts on that or some ideas please let me know. If removing the bs_dev from the clone/snapshot path doesn't result in a maj= or simplification, then it isn't worth doing. I thought that it might, since blob_bs_dev.c could be removed entirely. But you still do need some abstrac= tion for handling what to do when a blob is thin provisioned and needs to return zeroes, so maybe that negates any other simplifications. We can leave it low priority and think about it for awhile. Thanks, Ben --===============1586397616312721479==--