From: Trond Myklebust <trondmy@primarydata.com>
To: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"kolga@netapp.com" <kolga@netapp.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v3 1/1] PNFS fix dangling DS mount
Date: Thu, 20 Jul 2017 19:56:24 +0000 [thread overview]
Message-ID: <1500580582.5457.1.camel@primarydata.com> (raw)
In-Reply-To: <20170630195201.95597-1-kolga@netapp.com>
SGkgT2xnYSwNCg0KQXBvbG9naWVzIGZvciBtaXNzaW5nIHRoaXMgcGF0Y2guIEl0IHdhcyBoaWRp
bmcgaW4gbXkgJ2xpbnV4LWZzZGV2ZWwnDQptYWlsYm94LCBzbyBJIGRpZG4ndCByZWNvZ25pc2Ug
aXQgYXMgYSBORlMgcGF0Y2guDQoNCk9uIEZyaSwgMjAxNy0wNi0zMCBhdCAxNTo1MiAtMDQwMCwg
T2xnYSBLb3JuaWV2c2thaWEgd3JvdGU6DQo+IFRoZXJlIGlzIGEgcmVncmVzc2lvbiBieSBjb21t
aXQgOGQ0MGIwZjE0ODQ2ICgiTkZTIGZpbGVsYXlvdXQ6Y2FsbA0KPiBHRVRERVZJQ0VJTkZPIGFm
dGVyIHBuZnNfbGF5b3V0X3Byb2Nlc3MgY29tcGxldGVzIikuIEl0IGxlYXZlcyB0aGUNCj4gRFMg
bW91bnQgZGFuZ2xpbmcuDQo+IA0KPiBQcmV2aW91c2x5LCBmaWxlbGF5b3V0X2FsbG9jX3NlYygp
IHdvdWxkIGNhbGwNCj4gZmlsZWxheW91dF9jaGVja19sYXlvdXQoKQ0KPiB3aGljaCB3b3VsZCBj
YWxsIG5mczRfZmluZF9nZXRfZGV2aWNlaWQgd2hpY2ggdXBzIHRoZSBjb3VudCBvbiB0aGUNCj4g
ZGV2aWNlX2lkLiBJdCdzIG9ubHkgY2FsbGVkIG9uY2UgYW5kIGl0J3MgbWF0Y2hlZCBieSB0aGUN
Cj4gZmlsZWxheW91dF9mcmVlX2xzZWcoKSB0aGF0IGNhbGxzIG5mczRfZmxfcHV0X2RldmljZWlk
KCkuDQo+IA0KPiBBZnRlciB0aGF0IHBhdGNoLCBlYWNoIHJlYWQvd3JpdGUgZW5kcyB1cCBjYWxs
aW5nDQo+IG5mczRfZmluZF9nZXRfZGV2aWNlaWQNCj4gYW5kIHRoZXJlIGlzIG5vIGJhbGFuY2Ug
Zm9yIHRoYXQuIEluc3RlYWQsIGRvIG5mczRfZmxfcHV0X2RldmljZWlkKCkNCj4gaW4gdGhlIGZp
bGVsYXlvdXQncyAucGdfY2xlYW51cCBhbmQgcmVtb3ZlIGl0IGZyb20NCj4gZmlsZWxheW91dF9m
cmVlX2xzZWcuDQo+IA0KPiBCdXQgd2Ugc3RpbGwgbmVlZCBhIHJlZmVyZW5jZSB0byBob2xkIG92
ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZQ0KPiBzZWdtZW50Lg0KPiBGb3IgZXZlcnkgbmV3IGxzZWcg
dGhhdCdzIGNyZWF0ZWQgd2UgbmVlZCB0byB0YWtlIGEgcmVmZXJlbmNlIG9uDQo+IGRldmljZWlk
DQo+IHRoYXQgdXNlcyBpdC4gSXQgd2lsbCBiZSByZWxlYXNlZCBpbiB0aGUgImZyZWVfbHNlZyIg
cm91dGluZS4NCg0KVGhpcyBpcyB3aGF0IEknbSBub3QgdW5kZXJzdGFuZGluZy4gSWYgeW91IGhh
dmUgYSByZWZlcmVuY2UgaW4gdGhlDQpsYXlvdXQgc2VnbWVudCwgdGhlbiB3aHkgZG8geW91IG5l
ZWQgdG8gY2FsbCBuZnM0X2ZpbmRfZ2V0X2RldmljZWlkKCkNCmluIHRoZSByZWFkL3dyaXRlIGNv
ZGU/DQoNCklzbid0IGl0IHN1ZmZpY2llbnQgdG8gY2hhbmdlIHRoZSAicGdfaW5pdCIgY2FsbHMg
dG8gY2hlY2sgd2hldGhlciBvcg0Kbm90IHRoZSBzdHJ1Y3QgbmZzNF9maWxlbGF5b3V0X3NlZ21l
bnQgaGFzIHNldCBhIHZhbHVlIGZvciBkc2FkZHIgKHRoYXQNCm5lZWRzIHRvIGJlIGRvbmUgd2l0
aCBjYXJlIHRvIGF2b2lkIHJhY2VzIC0gY21weGNoZygpIGlzIHlvdXIgZnJpZW5kKSwNCmFuZCB0
aGVuIHJlbHkgb24gdGhhdCByZWZlcmVuY2UgYmVpbmcgc2V0IGZvciB0aGUgcmVtYWluZGVyIG9m
IHRoZQ0KbGF5b3V0IHNlZ21lbnQgbGlmZXRpbWU/DQoNCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QN
CkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lciwgUHJpbWFyeURhdGENCnRyb25kLm15a2xlYnVz
dEBwcmltYXJ5ZGF0YS5jb20NCg==
WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trondmy@primarydata.com>
To: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"kolga@netapp.com" <kolga@netapp.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v3 1/1] PNFS fix dangling DS mount
Date: Thu, 20 Jul 2017 19:56:24 +0000 [thread overview]
Message-ID: <1500580582.5457.1.camel@primarydata.com> (raw)
In-Reply-To: <20170630195201.95597-1-kolga@netapp.com>
Hi Olga,
Apologies for missing this patch. It was hiding in my 'linux-fsdevel'
mailbox, so I didn't recognise it as a NFS patch.
On Fri, 2017-06-30 at 15:52 -0400, Olga Kornievskaia wrote:
> There is a regression by commit 8d40b0f14846 ("NFS filelayout:call
> GETDEVICEINFO after pnfs_layout_process completes"). It leaves the
> DS mount dangling.
>
> Previously, filelayout_alloc_sec() would call
> filelayout_check_layout()
> which would call nfs4_find_get_deviceid which ups the count on the
> device_id. It's only called once and it's matched by the
> filelayout_free_lseg() that calls nfs4_fl_put_deviceid().
>
> After that patch, each read/write ends up calling
> nfs4_find_get_deviceid
> and there is no balance for that. Instead, do nfs4_fl_put_deviceid()
> in the filelayout's .pg_cleanup and remove it from
> filelayout_free_lseg.
>
> But we still need a reference to hold over the lifetime of the
> segment.
> For every new lseg that's created we need to take a reference on
> deviceid
> that uses it. It will be released in the "free_lseg" routine.
This is what I'm not understanding. If you have a reference in the
layout segment, then why do you need to call nfs4_find_get_deviceid()
in the read/write code?
Isn't it sufficient to change the "pg_init" calls to check whether or
not the struct nfs4_filelayout_segment has set a value for dsaddr (that
needs to be done with care to avoid races - cmpxchg() is your friend),
and then rely on that reference being set for the remainder of the
layout segment lifetime?
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com
next prev parent reply other threads:[~2017-07-20 19:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-30 19:52 [PATCH v3 1/1] PNFS fix dangling DS mount Olga Kornievskaia
2017-07-05 13:52 ` Steve Dickson
2017-07-20 19:56 ` Trond Myklebust [this message]
2017-07-20 19:56 ` Trond Myklebust
2017-07-20 20:14 ` Olga Kornievskaia
2017-07-20 21:09 ` Trond Myklebust
2017-07-21 15:46 ` Olga Kornievskaia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1500580582.5457.1.camel@primarydata.com \
--to=trondmy@primarydata.com \
--cc=kolga@netapp.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.