Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Date: Wed, 7 Oct 2015 22:38:21 +0300
From: Konstantin Boudnik <cos@apache.org>
To: dev@ignite.apache.org
Subject: Re: IGFS concurrency issue
Message-ID: <20151007193821.GC5947@tpx>
References: 
 <CAGt6o8=+fXR2QjNxpf4XkqsD0j3hPT_=iain2X346_O3QS40Gg@mail.gmail.com>
 <CA+eZwrG6iXBCb1-XwVmmcnDjkBKb1-_Y2_p86zPaTc_v_=eGGQ@mail.gmail.com>
 <20151007035739.GA16172@boudnik.org>
 <CAGt6o8mhSLku7mvA57D1GfZoy-msyLWpLnbPoUP08nMEQRxTCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="nHwqXXcoX0o6fKCv"
Content-Disposition: inline
In-Reply-To: 
 <CAGt6o8mhSLku7mvA57D1GfZoy-msyLWpLnbPoUP08nMEQRxTCg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

--nHwqXXcoX0o6fKCv
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 07, 2015 at 09:11AM, Vladimir Ozerov wrote:
> Cos,
> Yes, no long-time locking is expected here.

Sorry, I musta be still dense from the jet-lag: could you put in a bit more
details? Thanks in advance!

Cos

> On Wed, Oct 7, 2015 at 6:57 AM, Konstantin Boudnik <cos@apache.org> wrote:
>=20
> > IIRC NN should be locking on these ops anyway, shouldn't it? The situat=
ion
> > is
> > no different if multiple clients are doing these operations
> > near-simultaneously. Unless I missed something here...
> >
> > On Thu, Sep 24, 2015 at 11:28AM, Sergi Vladykin wrote:
> > > May be just check that they are not parent-child within the tx?
> > >
> > > Sergi
> > > Igniters,
> > >
> > > We revealed concurrency problem in IGFS and I would like to discuss
> > > possible solutions to it.
> > >
> > > Consider the following file system structure:
> > > root
> > > |-- A
> > > |   |-- B
> > > |   |   |-- C
> > > |   |-- D
> > >
> > > ... two concurrent operations in different threads:
> > > T1: move(/A/B, /A/D);
> > > T2: move(/A/D, /A/B/C);
> > >
> > > ... and how IGFS handles it now:
> > > T1: verify that "/A/B" and "/A/D" exist, they are not child-parent to
> > each
> > > other, etc. -> OK.
> > > T2: do the same for "A/D" and "A/B/C" -> OK.
> > > T1: get IDs of "/A", "/A/B" and "/A/D" to lock them later inside tx.
> > > T2: get IDs of "/A", "/A/D", "/A/B" and "/A/B/C" to lock them later
> > inside
> > > tx.
> > >
> > > T1: Start pessimistic tx, lock IDs of "/A", "/A/B", "/A/D", perform m=
ove
> > ->
> > > OK.
> > > root
> > > |-- A
> > > |   |-- D
> > > |   |   |-- B
> > > |   |   |   |-- C
> > >
> > > T2: Start pessimistic tx, lock IDs of "/A", "/A/D", "/A/B" and
> > > "/A/B/C" (*directory
> > > structure already changed at this time!*), perform move -> OK.
> > > root
> > > |-- A
> > > B
> > > |-- D
> > > |   |-- C
> > > |   |   |-- B (loop!)
> > >
> > > File system is corrupted. Folders B, C and D are not reacheable from
> > root.
> > >
> > > To fix this now we additionaly check if directory structure is still
> > > valid *inside
> > > transaction*. It works, no more corruptions. But it requres taking lo=
cks
> > on
> > > the whole paths *including root*. So move, delete and mkdirs opeartio=
ns
> > *can
> > > no longer be concurrent*.
> > >
> > > Probably there is a way to relax this while still ensuring consistenc=
y,
> > but
> > > I do not see how. One idea is to store real path inside each entry. T=
his
> > > way we will be able to ensure that it is still at a valid location
> > without
> > > blocking parents, so concurrnecy will be restored. But we will have to
> > > propagate strucutral changes to children. E.g. move of a folder with =
100
> > > items will lead to update of >100 cache entries. Not so good.
> > >
> > > Any other ideas?
> > >
> > > Vladimir.
> >

--nHwqXXcoX0o6fKCv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJWFXStAAoJEKtmQW7Qw4JPmgkH/jBtUq/ln+tZanU9BEMVnZ11
OBdPQW9zbaAt4ycQKR6uFJb7iDI/6+Khz4tY1Rf17nfsg5xBIlMQaNHJ4J4/Hqua
rEuGmQG3hx1ISFkYVLRqravsO507EZVHYm4BJk/1H0mPJB4pfdlDSJ6REkbG7DgH
ck5EilWPjrb5DGuaTGZWbiVsNf2jSvSXvBJQowj9gGCUZdwkiy0H3qeckjGVkC0H
C/po672mpU+skC76zP+TJ4QM5thJNr11AN84J9iMjgHSyTTw5/GJjFwI+fVPi9Et
tpYTM7DW6iwA269c4oJIPGz0PjEiZgpH1s/q/mNaUExO8NXGWVtqgnftaGxRKr4=
=hsE/
-----END PGP SIGNATURE-----

--nHwqXXcoX0o6fKCv--