Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   =?utf-8?Q?Javier_Gonz=C3=A1lez?= <javier@javigon.com>
Message-Id: <F305CAB7-F566-40D7-BC91-E88DE821520B@javigon.com>
Content-Type: multipart/signed;
        boundary="Apple-Mail=_D0EF968A-4724-4E5B-BE8B-7FBB785420C2";
        protocol="application/pgp-signature";
        micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Subject: Re: [PATCH] lightnvm: pblk: Introduce hot-cold data separation
Date:   Fri, 26 Apr 2019 12:04:19 +0200
In-Reply-To: <66434cc7-2bac-dd10-6edc-4560e6a0f89f@intel.com>
Cc:     Heiner Litz <hlitz@ucsc.edu>,
        =?utf-8?Q?Matias_Bj=C3=B8rling?= <mb@lightnvm.io>,
        Hans Holmberg <hans.holmberg@cnexlabs.com>,
        linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
To:     "Konopko, Igor J" <igor.j.konopko@intel.com>
References: <20190425052152.6571-1-hlitz@ucsc.edu>
 <66434cc7-2bac-dd10-6edc-4560e6a0f89f@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--Apple-Mail=_D0EF968A-4724-4E5B-BE8B-7FBB785420C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 26 Apr 2019, at 11.11, Igor Konopko <igor.j.konopko@intel.com> =
wrote:
>=20
> On 25.04.2019 07:21, Heiner Litz wrote:
>> Introduce the capability to manage multiple open lines. Maintain one =
line
>> for user writes (hot) and a second line for gc writes (cold). As user =
and
>> gc writes still utilize a shared ring buffer, in rare cases a =
multi-sector
>> write will contain both gc and user data. This is acceptable, as on a
>> tested SSD with minimum write size of 64KB, less than 1% of all =
writes
>> contain both hot and cold sectors.
>=20
> Hi Heiner
>=20
> Generally I really like this changes, I was thinking about sth similar =
since a while, so it is very good to see that patch.
>=20
> I have a one question related to this patch, since it is not very =
clear for me - how you ensure the data integrity in following scenarios:
> -we have open line X for user data and line Y for GC
> -GC writes LBA=3DN to line Y
> -user writes LBA=3DN to line X
> -we have power failure when both line X and Y were not written =
completely
> -during pblk creation we are executing OOB metadata recovery
> And here is the question, how we distinguish whether LBA=3DN from line =
Y or LBA=3DN from line X is the valid one?
> Line X and Y might have seq_id either descending or ascending - this =
would create two possible scenarios too.
>=20
> Thanks
> Igor
>=20

You are right, I think this is possible in the current implementation.

We need an extra constrain so that we only GC lines above the GC line
ID. This way, when we order lines on recovery, we can guarantee
consistency. This means potentially that we would need several open
lines for GC to avoid padding in case this constrain forces to choose a
line with an ID higher than the GC line ID.

What do you think?

Thanks,
Javier

--Apple-Mail=_D0EF968A-4724-4E5B-BE8B-7FBB785420C2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEU1dMZpvMIkj0jATvPEYBfS0leOAFAlzC16MACgkQPEYBfS0l
eODiWA/+NnPGXwCNAiRIGflg6iOCkHbPmUN+s9PhmEz1JYn0aPWhDz4lCRPEd+fX
JGFcg6CI/YpHE2Vm6YxpvqbzUgHe3LkJt3wPAEakLVHRRzbymtoU0f0sPnNibnJK
VcA227UPRzz7wHb8eZBG+ChzEA1EUgL+4/eUcRlzhNG4Ofog6uchZl36Y8R/wrqT
djuZq0ziFvI/y60gTgYP5KkKqS/mlMZw2OXYYfEJHCYEwMJ43lXfWHH7HeX7PYt9
lE2K4sIP9Q13N4l1XbqTctLv1ykaFdp73Mj3dwgz9wSbo5/rnYuoOY+B0igF39Y7
pqZA3akAjzGenKHjN7ufe0/+Dxx8pcKewfj4vH2RJ6rjs8Xb5hkNCpRzls8ZFmN9
QEHfxCwtZjt2/Zdey6cgVtkrBeaOXiSMqnuynGbFOLw/9zqAkzmzSP+rXLISqf6b
xKxxXjIWFUe5gAmEpVv92ejq1VGTooT8WXYyL+HsDnXMovsGZrgO8kPyyTNioHxP
vSyZ6Nvn2TyoWlaH6iILmJcLsm4pYpdr6ZeF3GbNH3I5DOfpHXjM4wbeH3+xAano
865HG0uySxZHIGf3OOuXXjsRemJPA1FN6MdyZ3eLwMFmM/CYBOBy2fqB7GhCM9KA
8eeOdP26FJdMb7cP42lYS1r8bkrYvP6pXBW3JH7YIUlMTwJx3Dc=
=1OCh
-----END PGP SIGNATURE-----

--Apple-Mail=_D0EF968A-4724-4E5B-BE8B-7FBB785420C2--