diff for duplicates of <1502430944.3822.1.camel@primarydata.com> diff --git a/a/1.txt b/N1/1.txt index 170b8e8..87ffed7 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,57 +1,84 @@ -T24gRnJpLCAyMDE3LTA4LTExIGF0IDE0OjMxICsxMDAwLCBOZWlsQnJvd24gd3JvdGU6DQo+IEZ1 -bm55IHN0b3J5LiAgNC41IHllYXJzIGFnbyB3ZSBkaXNjYXJkZWQgdGhlIEZTX1JFVkFMX0RPVCBz -dXBlcmJsb2NrDQo+IGZsYWcgYW5kIGludHJvZHVjZWQgdGhlIGRfd2Vha19yZXZhbGlkYXRlIGRl -bnRyeSBvcGVyYXRpb24gaW5zdGVhZC4NCj4gV2UgZHVseSByZW1vdmVkIHRoZSBmbGFnIGZyb20g -TkZTIHN1cGVyYmxvY2tzIGFuZCBORlN2NCBzdXBlcmJsb2NrcywNCj4gYW5kIGFkZGVkIHRoZSBu -ZXcgZGVudHJ5IG9wZXJhdGlvbiB0byBORlMgZGVudHJpZXMgLi4uLiBidXQgbm90IHRvDQo+IE5G -U3Y0DQo+IGRlbnRyaWVzLg0KPiANCj4gQW5kIG5vYm9keSBub3RpY2VkLg0KPiANCj4gVW50aWwg -dG9kYXkuDQo+IA0KPiBBIGN1c3RvbWVyIHJlcG9ydHMgYSBzaXR1YXRpb24gd2hlcmUgbW91bnQo -Li4uLixNU19SRU1PVU5ULC4uKSBvbiBhbg0KPiBORlMNCj4gZmlsZXN5c3RlbSBoYW5ncyBiZWNh -dXNlIHRoZSBuZXR3b3JrIGhhcyBiZWVuIGRlY29uZmlndXJlZC4gIFRoaXMNCj4gbWFrZXMNCj4g -cGVyZmVjdCBzZW5zZSBhbmQgSSBzdWdnZXN0ZWQgYSBjb2RlIGNoYW5nZSB0byBmaXggdGhlIHBy -b2JsZW0uDQo+IEhvd2V2ZXIgd2hlbiBhIGNvbGxlYWd1ZSB3YXMgdHJ5aW5nIHRvIHJlcHJvZHVj -ZSB0aGUgcHJvYmxlbSB0bw0KPiB2YWxpZGF0ZQ0KPiB0aGUgZml4LCBoZSBjb3VsZG4ndC4gIFRo -ZW4gbm9yIGNvdWxkIEkuDQo+IA0KPiBUaGUgcHJvYmxlbSBpcyB0cml2aWFsbHkgcmVwcm9kdWNp -YmxlIHdpdGggTkZTdjMsIGFuZCBub3QgYXQgYWxsIHdpdGgNCj4gTkZTdjQuICBUaGUgcmVhc29u -IGlzIHRoZSBtaXNzaW5nIGRfd2Vha19yZXZhbGlkYXRlLg0KPiANCj4gV2UgY291bGQgc2ltcGx5 -IGFkZCBkX3dlYWtfcmV2YWxpZGF0ZSBmb3IgTkZTdjQsIGJ1dCBnaXZlbiB0aGF0IGl0DQo+IGhh -cyBiZWVuIG1pc3NpbmcgZm9yIDQuNSB5ZWFycywgYW5kIHRoZSBvbmx5IHRpbWUgYW55b25lIG5v -dGljZWQgd2FzDQo+IHdoZW4gdGhlIG9tbWlzc2lvbiByZXN1bHRlZCBpbiBhIGJldHRlciB1c2Vy -IGV4cGVyaWVuY2UsIEkgZG8gd29uZGVyDQo+IGlmDQo+IHdlIG5lZWQgdG8uICBDYW4gd2UganVz -dCBkaXNjYXJkIGRfd2Vha19yZXZhbGlkYXRlPyAgV2hhdCBwdXJwb3NlDQo+IGRvZXMNCj4gaXQg -c2VydmU/ICBJIGNvdWxkbid0IGZpbmQgb25lLg0KPiANCj4gVGhhbmtzLA0KPiBOZWlsQnJvd24N -Cj4gDQo+IEZvciByZWZlcmVuY2UsIHNlZQ0KPiBDb21taXQ6IGVjZjNkMWYxYWE3NCAoInZmczog -a2lsbCBGU19SRVZBTF9ET1QgYnkgYWRkaW5nIGENCj4gZF93ZWFrX3JldmFsaWRhdGUgZGVudHJ5 -IG9wIikNCj4gDQo+IA0KPiANCj4gVG8gcmVwcm9kdWNlIHRoZSBwcm9ibGVtIGF0IGhvbWUsIG9u -IGEgc3lzdGVtIHRoYXQgdXNlcyBzeXN0ZW1kOg0KPiAxLyBwbGFjZSAob3IgZmluZCkgYSBmaWxl -c3lzdGVtIGltYWdlIGluIGEgZmlsZSBvbiBhbiBORlMgZmlsZXN5c3RlbS4NCj4gMi8gbW91bnQg -dGhlIG5mcyBmaWxlc3lzdGVtIHdpdGggIm5vYWMiIC0gY2hvb3NlIHYzIG9yIHY0DQo+IDMvIGxv -b3AtbW91bnQgdGhlIGZpbGVzeXN0ZW0gaW1hZ2UgcmVhZC1vbmx5IHNvbWV3aGVyZQ0KPiA0LyBy -ZWJvb3QNCj4gDQo+IElmIHlvdSBjaG9vc2UgdjQsIHRoZSByZWJvb3Qgd2lsbCBzdWNjZWVkLCBw -b3NzaWJseSBhZnRlciBhIDkwc2Vjb25kDQo+IHRpbWVvdXQuDQo+IElmIHlvdSBjaG9vc2UgdjMs -IHRoZSByZWJvb3Qgd2lsbCBoYW5nIGluZGVmaW5pdGVseSBpbiBzeXN0ZW1kLQ0KPiBzaHV0ZG93 -biB3aGlsZQ0KPiByZW1vdW50aW5nIHRoZSBuZnMgZmlsZXN5c3RlbSByZWFkLW9ubHkuDQo+IA0K -PiBJZiB5b3UgZG9uJ3QgdXNlICJub2FjIiBpdCBjYW4gc3RpbGwgaGFuZywgYnV0IG9ubHkgaWYg -c29tZXRoaW5nDQo+IHNsb3dzDQo+IGRvd24gdGhlIHJlYm9vdCBlbm91Z2ggdGhhdCBhdHRyaWJ1 -dGVzIGhhdmUgdGltZWQgb3V0IGJ5IHRoZSB0aW1lDQo+IHRoYXQNCj4gc3lzdGVtZC1zaHV0ZG93 -biBydW5zLiAgVGhpcyBoYXBwZW5zIGZvciBvdXIgY3VzdG9tZXIuDQo+IA0KPiBJZiB0aGUgbG9v -cC1tb3VudGVkIGZpbGVzeXN0ZW0gaXMgbm90IHJlYWQtb25seSwgeW91IGdldCBvdGhlcg0KPiBw -cm9ibGVtcy4NCj4gDQo+IFdlIHJlYWxseSB3YW50IHN5c3RlbWQgdG8gZmlndXJlIG91dCB0aGF0 -IHRoZSBsb29wLW1vdW50IG5lZWRzIHRvIGJlDQo+IHVubW91bnRlZCBmaXJzdC4gIEkgaGF2ZSBp -ZGVhcyBjb25jZXJuaW5nIHRoYXQsIGJ1dCBpdCBpcyBtZXNzeS4gIEJ1dA0KPiB0aGF0IGlzbid0 -IHRoZSBvbmx5IGJ1ZyBoZXJlLg0KDQpUaGUgbWFpbiBwdXJwb3NlIG9mIGRfd2Vha19yZXZhbGlk -YXRlKCkgd2FzIHRvIGNhdGNoIHRoZSBpc3N1ZXMgdGhhdA0KYXJpc2Ugd2hlbiBzb21lb25lIGNo -YW5nZXMgdGhlIGNvbnRlbnRzIG9mIHRoZSBjdXJyZW50IHdvcmtpbmcNCmRpcmVjdG9yeSBvciBp -dHMgcGFyZW50IG9uIHRoZSBzZXJ2ZXIuIFNpbmNlICcuJyBhbmQgJy4uJyBhcmUgdHJlYXRlZA0K -c3BlY2lhbGx5IGluIHRoZSBsb29rdXAgY29kZSwgdGhleSB3b3VsZCBub3QgYmUgcmV2YWxpZGF0 -ZWQgd2l0aG91dA0Kc3BlY2lhbCB0cmVhdG1lbnQuIFRoYXQgbGVhZHMgdG8gaXNzdWVzIHdoZW4g -bG9va2luZyB1cCBmaWxlcyBhcw0KLi88ZmlsZW5hbWU+IG9yIC4uLzxmaWxlbmFtZT4sIHNpbmNl -IHRoZSBjbGllbnQgd29uJ3QgZGV0ZWN0IHRoYXQgaXRzDQpkY2FjaGUgaXMgc3RhbGUgdW50aWwg -aXQgdHJpZXMgdG8gdXNlIHRoZSBjYWNoZWQgZGVudHJ5K2lub2RlLg0KDQpUaGUgb25lIHRoaW5n -IHRoYXQgaGFzIGNoYW5nZWQgc2luY2UgaXRzIGludHJvZHVjdGlvbiBpcywgSSBiZWxpZXZlLA0K -dGhlIEVTVEFMRSBoYW5kbGluZyBpbiB0aGUgVkZTIGxheWVyLiBUaGF0IG1pZ2h0IGZpeCBhIGxv -dCBvZiB0aGUNCmRjYWNoZSBsb29rdXAgYnVncyB0aGF0IHdlcmUgcHJldmlvdXNseSBoYW5kbGVk -IGJ5IGRfd2Vha19yZXZhbGlkYXRlKCkuDQpJIGhhdmVuJ3QgZG9uZSBhbiBhdWRpdCB0byBmaWd1 -cmUgb3V0IGlmIGl0IGFjdHVhbGx5IGNhbiBoYW5kbGUgYWxsIG9mDQp0aGVtLg0KDQotLSANClRy -b25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyLCBQcmltYXJ5RGF0YQ0K -dHJvbmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbQ0K +On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote: +> Funny story. 4.5 years ago we discarded the FS_REVAL_DOT superblock +> flag and introduced the d_weak_revalidate dentry operation instead. +> We duly removed the flag from NFS superblocks and NFSv4 superblocks, +> and added the new dentry operation to NFS dentries .... but not to +> NFSv4 +> dentries. +> +> And nobody noticed. +> +> Until today. +> +> A customer reports a situation where mount(....,MS_REMOUNT,..) on an +> NFS +> filesystem hangs because the network has been deconfigured. This +> makes +> perfect sense and I suggested a code change to fix the problem. +> However when a colleague was trying to reproduce the problem to +> validate +> the fix, he couldn't. Then nor could I. +> +> The problem is trivially reproducible with NFSv3, and not at all with +> NFSv4. The reason is the missing d_weak_revalidate. +> +> We could simply add d_weak_revalidate for NFSv4, but given that it +> has been missing for 4.5 years, and the only time anyone noticed was +> when the ommission resulted in a better user experience, I do wonder +> if +> we need to. Can we just discard d_weak_revalidate? What purpose +> does +> it serve? I couldn't find one. +> +> Thanks, +> NeilBrown +> +> For reference, see +> Commit: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a +> d_weak_revalidate dentry op") +> +> +> +> To reproduce the problem at home, on a system that uses systemd: +> 1/ place (or find) a filesystem image in a file on an NFS filesystem. +> 2/ mount the nfs filesystem with "noac" - choose v3 or v4 +> 3/ loop-mount the filesystem image read-only somewhere +> 4/ reboot +> +> If you choose v4, the reboot will succeed, possibly after a 90second +> timeout. +> If you choose v3, the reboot will hang indefinitely in systemd- +> shutdown while +> remounting the nfs filesystem read-only. +> +> If you don't use "noac" it can still hang, but only if something +> slows +> down the reboot enough that attributes have timed out by the time +> that +> systemd-shutdown runs. This happens for our customer. +> +> If the loop-mounted filesystem is not read-only, you get other +> problems. +> +> We really want systemd to figure out that the loop-mount needs to be +> unmounted first. I have ideas concerning that, but it is messy. But +> that isn't the only bug here. + +The main purpose of d_weak_revalidate() was to catch the issues that +arise when someone changes the contents of the current working +directory or its parent on the server. Since '.' and '..' are treated +specially in the lookup code, they would not be revalidated without +special treatment. That leads to issues when looking up files as +./<filename> or ../<filename>, since the client won't detect that its +dcache is stale until it tries to use the cached dentry+inode. + +The one thing that has changed since its introduction is, I believe, +the ESTALE handling in the VFS layer. That might fix a lot of the +dcache lookup bugs that were previously handled by d_weak_revalidate(). +I haven't done an audit to figure out if it actually can handle all of +them. + +-- +Trond Myklebust +Linux NFS client maintainer, PrimaryData +trond.myklebust@primarydata.com diff --git a/a/content_digest b/N1/content_digest index ef95d57..528464b 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -11,62 +11,89 @@ " linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>\0" "\00:1\0" "b\0" - "T24gRnJpLCAyMDE3LTA4LTExIGF0IDE0OjMxICsxMDAwLCBOZWlsQnJvd24gd3JvdGU6DQo+IEZ1\n" - "bm55IHN0b3J5LiAgNC41IHllYXJzIGFnbyB3ZSBkaXNjYXJkZWQgdGhlIEZTX1JFVkFMX0RPVCBz\n" - "dXBlcmJsb2NrDQo+IGZsYWcgYW5kIGludHJvZHVjZWQgdGhlIGRfd2Vha19yZXZhbGlkYXRlIGRl\n" - "bnRyeSBvcGVyYXRpb24gaW5zdGVhZC4NCj4gV2UgZHVseSByZW1vdmVkIHRoZSBmbGFnIGZyb20g\n" - "TkZTIHN1cGVyYmxvY2tzIGFuZCBORlN2NCBzdXBlcmJsb2NrcywNCj4gYW5kIGFkZGVkIHRoZSBu\n" - "ZXcgZGVudHJ5IG9wZXJhdGlvbiB0byBORlMgZGVudHJpZXMgLi4uLiBidXQgbm90IHRvDQo+IE5G\n" - "U3Y0DQo+IGRlbnRyaWVzLg0KPiANCj4gQW5kIG5vYm9keSBub3RpY2VkLg0KPiANCj4gVW50aWwg\n" - "dG9kYXkuDQo+IA0KPiBBIGN1c3RvbWVyIHJlcG9ydHMgYSBzaXR1YXRpb24gd2hlcmUgbW91bnQo\n" - "Li4uLixNU19SRU1PVU5ULC4uKSBvbiBhbg0KPiBORlMNCj4gZmlsZXN5c3RlbSBoYW5ncyBiZWNh\n" - "dXNlIHRoZSBuZXR3b3JrIGhhcyBiZWVuIGRlY29uZmlndXJlZC4gIFRoaXMNCj4gbWFrZXMNCj4g\n" - "cGVyZmVjdCBzZW5zZSBhbmQgSSBzdWdnZXN0ZWQgYSBjb2RlIGNoYW5nZSB0byBmaXggdGhlIHBy\n" - "b2JsZW0uDQo+IEhvd2V2ZXIgd2hlbiBhIGNvbGxlYWd1ZSB3YXMgdHJ5aW5nIHRvIHJlcHJvZHVj\n" - "ZSB0aGUgcHJvYmxlbSB0bw0KPiB2YWxpZGF0ZQ0KPiB0aGUgZml4LCBoZSBjb3VsZG4ndC4gIFRo\n" - "ZW4gbm9yIGNvdWxkIEkuDQo+IA0KPiBUaGUgcHJvYmxlbSBpcyB0cml2aWFsbHkgcmVwcm9kdWNp\n" - "YmxlIHdpdGggTkZTdjMsIGFuZCBub3QgYXQgYWxsIHdpdGgNCj4gTkZTdjQuICBUaGUgcmVhc29u\n" - "IGlzIHRoZSBtaXNzaW5nIGRfd2Vha19yZXZhbGlkYXRlLg0KPiANCj4gV2UgY291bGQgc2ltcGx5\n" - "IGFkZCBkX3dlYWtfcmV2YWxpZGF0ZSBmb3IgTkZTdjQsIGJ1dCBnaXZlbiB0aGF0IGl0DQo+IGhh\n" - "cyBiZWVuIG1pc3NpbmcgZm9yIDQuNSB5ZWFycywgYW5kIHRoZSBvbmx5IHRpbWUgYW55b25lIG5v\n" - "dGljZWQgd2FzDQo+IHdoZW4gdGhlIG9tbWlzc2lvbiByZXN1bHRlZCBpbiBhIGJldHRlciB1c2Vy\n" - "IGV4cGVyaWVuY2UsIEkgZG8gd29uZGVyDQo+IGlmDQo+IHdlIG5lZWQgdG8uICBDYW4gd2UganVz\n" - "dCBkaXNjYXJkIGRfd2Vha19yZXZhbGlkYXRlPyAgV2hhdCBwdXJwb3NlDQo+IGRvZXMNCj4gaXQg\n" - "c2VydmU/ICBJIGNvdWxkbid0IGZpbmQgb25lLg0KPiANCj4gVGhhbmtzLA0KPiBOZWlsQnJvd24N\n" - "Cj4gDQo+IEZvciByZWZlcmVuY2UsIHNlZQ0KPiBDb21taXQ6IGVjZjNkMWYxYWE3NCAoInZmczog\n" - "a2lsbCBGU19SRVZBTF9ET1QgYnkgYWRkaW5nIGENCj4gZF93ZWFrX3JldmFsaWRhdGUgZGVudHJ5\n" - "IG9wIikNCj4gDQo+IA0KPiANCj4gVG8gcmVwcm9kdWNlIHRoZSBwcm9ibGVtIGF0IGhvbWUsIG9u\n" - "IGEgc3lzdGVtIHRoYXQgdXNlcyBzeXN0ZW1kOg0KPiAxLyBwbGFjZSAob3IgZmluZCkgYSBmaWxl\n" - "c3lzdGVtIGltYWdlIGluIGEgZmlsZSBvbiBhbiBORlMgZmlsZXN5c3RlbS4NCj4gMi8gbW91bnQg\n" - "dGhlIG5mcyBmaWxlc3lzdGVtIHdpdGggIm5vYWMiIC0gY2hvb3NlIHYzIG9yIHY0DQo+IDMvIGxv\n" - "b3AtbW91bnQgdGhlIGZpbGVzeXN0ZW0gaW1hZ2UgcmVhZC1vbmx5IHNvbWV3aGVyZQ0KPiA0LyBy\n" - "ZWJvb3QNCj4gDQo+IElmIHlvdSBjaG9vc2UgdjQsIHRoZSByZWJvb3Qgd2lsbCBzdWNjZWVkLCBw\n" - "b3NzaWJseSBhZnRlciBhIDkwc2Vjb25kDQo+IHRpbWVvdXQuDQo+IElmIHlvdSBjaG9vc2UgdjMs\n" - "IHRoZSByZWJvb3Qgd2lsbCBoYW5nIGluZGVmaW5pdGVseSBpbiBzeXN0ZW1kLQ0KPiBzaHV0ZG93\n" - "biB3aGlsZQ0KPiByZW1vdW50aW5nIHRoZSBuZnMgZmlsZXN5c3RlbSByZWFkLW9ubHkuDQo+IA0K\n" - "PiBJZiB5b3UgZG9uJ3QgdXNlICJub2FjIiBpdCBjYW4gc3RpbGwgaGFuZywgYnV0IG9ubHkgaWYg\n" - "c29tZXRoaW5nDQo+IHNsb3dzDQo+IGRvd24gdGhlIHJlYm9vdCBlbm91Z2ggdGhhdCBhdHRyaWJ1\n" - "dGVzIGhhdmUgdGltZWQgb3V0IGJ5IHRoZSB0aW1lDQo+IHRoYXQNCj4gc3lzdGVtZC1zaHV0ZG93\n" - "biBydW5zLiAgVGhpcyBoYXBwZW5zIGZvciBvdXIgY3VzdG9tZXIuDQo+IA0KPiBJZiB0aGUgbG9v\n" - "cC1tb3VudGVkIGZpbGVzeXN0ZW0gaXMgbm90IHJlYWQtb25seSwgeW91IGdldCBvdGhlcg0KPiBw\n" - "cm9ibGVtcy4NCj4gDQo+IFdlIHJlYWxseSB3YW50IHN5c3RlbWQgdG8gZmlndXJlIG91dCB0aGF0\n" - "IHRoZSBsb29wLW1vdW50IG5lZWRzIHRvIGJlDQo+IHVubW91bnRlZCBmaXJzdC4gIEkgaGF2ZSBp\n" - "ZGVhcyBjb25jZXJuaW5nIHRoYXQsIGJ1dCBpdCBpcyBtZXNzeS4gIEJ1dA0KPiB0aGF0IGlzbid0\n" - "IHRoZSBvbmx5IGJ1ZyBoZXJlLg0KDQpUaGUgbWFpbiBwdXJwb3NlIG9mIGRfd2Vha19yZXZhbGlk\n" - "YXRlKCkgd2FzIHRvIGNhdGNoIHRoZSBpc3N1ZXMgdGhhdA0KYXJpc2Ugd2hlbiBzb21lb25lIGNo\n" - "YW5nZXMgdGhlIGNvbnRlbnRzIG9mIHRoZSBjdXJyZW50IHdvcmtpbmcNCmRpcmVjdG9yeSBvciBp\n" - "dHMgcGFyZW50IG9uIHRoZSBzZXJ2ZXIuIFNpbmNlICcuJyBhbmQgJy4uJyBhcmUgdHJlYXRlZA0K\n" - "c3BlY2lhbGx5IGluIHRoZSBsb29rdXAgY29kZSwgdGhleSB3b3VsZCBub3QgYmUgcmV2YWxpZGF0\n" - "ZWQgd2l0aG91dA0Kc3BlY2lhbCB0cmVhdG1lbnQuIFRoYXQgbGVhZHMgdG8gaXNzdWVzIHdoZW4g\n" - "bG9va2luZyB1cCBmaWxlcyBhcw0KLi88ZmlsZW5hbWU+IG9yIC4uLzxmaWxlbmFtZT4sIHNpbmNl\n" - "IHRoZSBjbGllbnQgd29uJ3QgZGV0ZWN0IHRoYXQgaXRzDQpkY2FjaGUgaXMgc3RhbGUgdW50aWwg\n" - "aXQgdHJpZXMgdG8gdXNlIHRoZSBjYWNoZWQgZGVudHJ5K2lub2RlLg0KDQpUaGUgb25lIHRoaW5n\n" - "IHRoYXQgaGFzIGNoYW5nZWQgc2luY2UgaXRzIGludHJvZHVjdGlvbiBpcywgSSBiZWxpZXZlLA0K\n" - "dGhlIEVTVEFMRSBoYW5kbGluZyBpbiB0aGUgVkZTIGxheWVyLiBUaGF0IG1pZ2h0IGZpeCBhIGxv\n" - "dCBvZiB0aGUNCmRjYWNoZSBsb29rdXAgYnVncyB0aGF0IHdlcmUgcHJldmlvdXNseSBoYW5kbGVk\n" - "IGJ5IGRfd2Vha19yZXZhbGlkYXRlKCkuDQpJIGhhdmVuJ3QgZG9uZSBhbiBhdWRpdCB0byBmaWd1\n" - "cmUgb3V0IGlmIGl0IGFjdHVhbGx5IGNhbiBoYW5kbGUgYWxsIG9mDQp0aGVtLg0KDQotLSANClRy\n" - "b25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyLCBQcmltYXJ5RGF0YQ0K\n" - dHJvbmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbQ0K + "On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:\n" + "> Funny story. 4.5 years ago we discarded the FS_REVAL_DOT superblock\n" + "> flag and introduced the d_weak_revalidate dentry operation instead.\n" + "> We duly removed the flag from NFS superblocks and NFSv4 superblocks,\n" + "> and added the new dentry operation to NFS dentries .... but not to\n" + "> NFSv4\n" + "> dentries.\n" + "> \n" + "> And nobody noticed.\n" + "> \n" + "> Until today.\n" + "> \n" + "> A customer reports a situation where mount(....,MS_REMOUNT,..) on an\n" + "> NFS\n" + "> filesystem hangs because the network has been deconfigured. This\n" + "> makes\n" + "> perfect sense and I suggested a code change to fix the problem.\n" + "> However when a colleague was trying to reproduce the problem to\n" + "> validate\n" + "> the fix, he couldn't. Then nor could I.\n" + "> \n" + "> The problem is trivially reproducible with NFSv3, and not at all with\n" + "> NFSv4. The reason is the missing d_weak_revalidate.\n" + "> \n" + "> We could simply add d_weak_revalidate for NFSv4, but given that it\n" + "> has been missing for 4.5 years, and the only time anyone noticed was\n" + "> when the ommission resulted in a better user experience, I do wonder\n" + "> if\n" + "> we need to. Can we just discard d_weak_revalidate? What purpose\n" + "> does\n" + "> it serve? I couldn't find one.\n" + "> \n" + "> Thanks,\n" + "> NeilBrown\n" + "> \n" + "> For reference, see\n" + "> Commit: ecf3d1f1aa74 (\"vfs: kill FS_REVAL_DOT by adding a\n" + "> d_weak_revalidate dentry op\")\n" + "> \n" + "> \n" + "> \n" + "> To reproduce the problem at home, on a system that uses systemd:\n" + "> 1/ place (or find) a filesystem image in a file on an NFS filesystem.\n" + "> 2/ mount the nfs filesystem with \"noac\" - choose v3 or v4\n" + "> 3/ loop-mount the filesystem image read-only somewhere\n" + "> 4/ reboot\n" + "> \n" + "> If you choose v4, the reboot will succeed, possibly after a 90second\n" + "> timeout.\n" + "> If you choose v3, the reboot will hang indefinitely in systemd-\n" + "> shutdown while\n" + "> remounting the nfs filesystem read-only.\n" + "> \n" + "> If you don't use \"noac\" it can still hang, but only if something\n" + "> slows\n" + "> down the reboot enough that attributes have timed out by the time\n" + "> that\n" + "> systemd-shutdown runs. This happens for our customer.\n" + "> \n" + "> If the loop-mounted filesystem is not read-only, you get other\n" + "> problems.\n" + "> \n" + "> We really want systemd to figure out that the loop-mount needs to be\n" + "> unmounted first. I have ideas concerning that, but it is messy. But\n" + "> that isn't the only bug here.\n" + "\n" + "The main purpose of d_weak_revalidate() was to catch the issues that\n" + "arise when someone changes the contents of the current working\n" + "directory or its parent on the server. Since '.' and '..' are treated\n" + "specially in the lookup code, they would not be revalidated without\n" + "special treatment. That leads to issues when looking up files as\n" + "./<filename> or ../<filename>, since the client won't detect that its\n" + "dcache is stale until it tries to use the cached dentry+inode.\n" + "\n" + "The one thing that has changed since its introduction is, I believe,\n" + "the ESTALE handling in the VFS layer. That might fix a lot of the\n" + "dcache lookup bugs that were previously handled by d_weak_revalidate().\n" + "I haven't done an audit to figure out if it actually can handle all of\n" + "them.\n" + "\n" + "-- \n" + "Trond Myklebust\n" + "Linux NFS client maintainer, PrimaryData\n" + trond.myklebust@primarydata.com -d8d69c27cc7def0d1f700ee08d96e4da04023318f4376e4a1b6e3e912363e4a9 +d3d906fa68c54271c796c0c3085187fb46c8c62d4e9d50605a48512aab0ee7c5
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.