Date: Thu, 1 Sep 2022 20:31:16 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: SEEK_DATA/SEEK_HOLE with vnode locked Message-ID: <YQXPR01MB4150BC25A9767E42251730DFDD7B9@YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <YwgPTd%2B1LViZrVxz@kib.kiev.ua> References: <YQBPR0101MB97420AD41791E544519A0A2DDD659@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM> <YvQ7MYXPl0AugojS@kib.kiev.ua> <YT4PR01MB9736B24FDE64C945C2C9EC8EDD6F9@YT4PR01MB9736.CANPRD01.PROD.OUTLOOK.COM> <YwJXuz5DsuOmyA6t@kib.kiev.ua> <YT4PR01MB9736D37382DF089F784C3C82DD6E9@YT4PR01MB9736.CANPRD01.PROD.OUTLOOK.COM> <YwgPTd%2B1LViZrVxz@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--_003_YQXPR01MB4150BC25A9767E42251730DFDD7B9YQXPR01MB4150CANP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Konstantin Belousov <kostikbel@gmail.com> wrote:=0A=
[stuff snipped]=0A=
>Could you arrange some local test, without NFS, please?=0A=
>I might try to take a look at UFS then.=0A=
Well, the two attached trivial programs seem to demonstrate=0A=
the problem. crsparse.c just creates a sparse file, then readsparse.c=0A=
reads the file, either with just read(2) or using SEEK_HOLE/SEEK_DATA=0A=
if "-s" is specified on the command line.=0A=
$ crsparse xxx=0A=
$ time readsparse xxx=0A=
$ time readsparse xxx=0A=
$ time readsparse -s xxx=0A=
$ time readsparse -s xxx=0A=
=0A=
However, when you look at readsparse.c, you will note that it=0A=
does the reading in 1Mbyte chunks, which is what the NFS server=0A=
will see for ReadPlus.=0A=
If you modify it to do the reading in large chunks, there is no=0A=
longer a performance problem.=0A=
=0A=
In summary, I think the performance problem is pretty=0A=
specific to how ReadPlus would use SEEK_DATA/SEEK_HOLE,=0A=
so I doubt it is worth exploring?=0A=
=0A=
Btw, Linux has now decided to implement ReadPlus just like=0A=
Read and not look for/process holes. They are convinced=0A=
that ReadPlus can only efficiently find holes if there is a file=0A=
system specific method (ie. a VOP call for FreeBSD) that returns=0A=
both data and holes. Until then, ReadPlus won't be any different=0A=
than Read for them.=0A=
--> I could do this, but I don't see any point, at this time.=0A=
It also appears to violate the intent of ReadPlus in the RFC,=0A=
if not actually a strict violation of the RFC.=0A=
=0A=
rick=0A=
ps: readsparse.c works well either way for ZFS, so it was some=0A=
other mysterious weirdness that caused ZFS to be really=0A=
slow for ReadPlus?=0A=
=0A=
--_003_YQXPR01MB4150BC25A9767E42251730DFDD7B9YQXPR01MB4150CANP_
Content-Type: text/plain; name="crsparse.c"
Content-Description: crsparse.c
Content-Disposition: attachment; filename="crsparse.c"; size=748;
creation-date="Thu, 01 Sep 2022 20:30:47 GMT";
modification-date="Thu, 01 Sep 2022 20:30:47 GMT"
Content-Transfer-Encoding: base64
I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5o
PgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxzeXMvcGFy
YW0uaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3N0YXQuaD4KI2luY2x1
ZGUgPGVyci5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CgpzdGF0aWMgY2hhciBvdXRidWZbMTA0ODU3
Nl07CgppbnQKbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQp7CglpbnQgaSwgb3V0ZmQ7Cglj
aGFyIGNwOwoKCWlmIChhcmdjICE9IDIpCgkJZXJyeCgxLCAiVXNhZ2U6IGNyc3BhcnNlIDxvdXRm
aWxlPiIpOwoJLyogRmlsbCBpbiBvdXRidWYgd2l0aCB0aGUgYWxwaGFiZXQuICovCgljcCA9ICdh
JzsKCWZvciAoaSA9IDA7IGkgPCBzaXplb2Yob3V0YnVmKTsgaSsrKSB7CgkJb3V0YnVmW2ldID0g
Y3ArKzsKCQlpZiAoY3AgPiAneicpCgkJCWNwID0gJ2EnOwoJfQoJb3V0ZmQgPSBvcGVuKGFyZ3Zb
MV0sIE9fQ1JFQVQgfCBPX1JEV1IsIDA2NDQpOwoJaWYgKG91dGZkIDwgMCkKCQllcnIoMSwgImNh
bid0IG9wZW4gJXMiLCBhcmd2WzFdKTsKCgkvKiBDcmVhdGUgdGhlIHNwYXJzZSBmaWxlLiAqLwoJ
bHNlZWsob3V0ZmQsIDEwMjQgKiBzaXplb2Yob3V0YnVmKSwgU0VFS19DVVIpOwoJZm9yIChpID0g
MDsgaSA8IDI1NjsgaSsrKSB7CgkJd3JpdGUob3V0ZmQsIG91dGJ1Ziwgc2l6ZW9mKG91dGJ1Zikp
OwoJfQp9Cg==
--_003_YQXPR01MB4150BC25A9767E42251730DFDD7B9YQXPR01MB4150CANP_
Content-Type: text/plain; name="readsparse.c"
Content-Description: readsparse.c
Content-Disposition: attachment; filename="readsparse.c"; size=2141;
creation-date="Thu, 01 Sep 2022 20:31:11 GMT";
modification-date="Thu, 01 Sep 2022 20:31:11 GMT"
Content-Transfer-Encoding: base64
I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5o
PgojaW5jbHVkZSA8c3RkYm9vbC5oPgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPGVycm5v
Lmg+CiNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVk
ZSA8c3lzL3N0YXQuaD4KI2luY2x1ZGUgPGVyci5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CiNpbmNs
dWRlIDxnZXRvcHQuaD4KCmNoYXIgYnVmWzEwMjQgKiAxMDI0XTsKCi8qIFJlYWQgMU1ieXRlIHVz
aW5nIFNFRUtfREFUQS9TRUVLX0hPTEUuICovCnNzaXplX3QKcmVhZHNwMW0oY2hhciAqaW5maWxl
LCBvZmZfdCBvZmZwb3MpCnsKCWludCBpbmZkOwoJb2ZmX3Qgc2Vla2RhdGEsIHNlZWtob2xlOwoJ
c2l6ZV90IGxlbiwgeGZlcjsKCXNzaXplX3QgcnNpejsKCglpbmZkID0gb3BlbihpbmZpbGUsIE9f
UkRPTkxZLCAwKTsKCWlmIChpbmZkIDwgMCkKCQllcnIoMSwgImNhbid0IG9wZW4gJXMiLCBpbmZp
bGUpOwoKCXNlZWtkYXRhID0gbHNlZWsoaW5mZCwgb2ZmcG9zLCBTRUVLX0RBVEEpOwoJaWYgKHNl
ZWtkYXRhIDwgMCkKCQlyZXR1cm4gKDApOwoJaWYgKHNlZWtkYXRhID49IG9mZnBvcyArIDEwMjQg
KiAxMDI0KQoJCXJldHVybiAoMTAyNCAqIDEwMjQpOwoJbGVuID0gMTAyNCAqIDEwMjQ7CglpZiAo
c2Vla2RhdGEgPiBvZmZwb3MpCgkJbGVuIC09IHNlZWtkYXRhIC0gb2ZmcG9zOwoJZG8gewoJCXNl
ZWtob2xlID0gbHNlZWsoaW5mZCwgc2Vla2RhdGEsIFNFRUtfSE9MRSk7CgkJaWYgKHNlZWtob2xl
ID4gb2ZmcG9zICsgMTAyNCAqIDEwMjQpCgkJCXNlZWtob2xlID0gb2ZmcG9zICsgMTAyNCAqIDEw
MjQ7CgkJeGZlciA9IGxlbjsKCQlpZiAoc2Vla2hvbGUgLSBzZWVrZGF0YSA8IHhmZXIpCgkJCXhm
ZXIgPSBzZWVraG9sZSAtIHNlZWtkYXRhOwoJCWlmICh4ZmVyID4gMCkgewoJCQlpZiAobHNlZWso
aW5mZCwgc2Vla2RhdGEsIFNFRUtfU0VUKSA8IDApCgkJCQllcnIoMSwgIkxzZWVrIHNldCBmYWls
ZWQiKTsKCQkJcnNpeiA9IHJlYWQoaW5mZCwgYnVmLCB4ZmVyKTsKCQkJaWYgKHJzaXogPCAwKQoJ
CQkJZXJyKDEsICJSZWFkIHJldHVybmVkICVsZCIsIHJzaXopOwoJCQlsZW4gLT0geGZlcjsKCQl9
CgkJc2Vla2RhdGEgPSBsc2VlayhpbmZkLCBzZWVraG9sZSwgU0VFS19EQVRBKTsKCX0gd2hpbGUg
KHNlZWtkYXRhID49IDAgJiYgc2Vla2RhdGEgPCBvZmZwb3MpOwoJY2xvc2UoaW5mZCk7CglyZXR1
cm4gKDEwMjQgKiAxMDI0KTsKfQoKLyogUmVhZCAxTWJ5dGUuICovCnNzaXplX3QKcmVhZDFtKGNo
YXIgKmluZmlsZSwgb2ZmX3Qgb2ZmcG9zKQp7CglpbnQgaW5mZDsKCXNzaXplX3QgcnNpejsKCglp
bmZkID0gb3BlbihpbmZpbGUsIE9fUkRPTkxZLCAwKTsKCWlmIChpbmZkIDwgMCkKCQllcnIoMSwg
ImNhbid0IG9wZW4gJXMiLCBpbmZpbGUpOwoKCWlmIChsc2VlayhpbmZkLCBvZmZwb3MsIFNFRUtf
U0VUKSA8IDApCgkJZXJyKDEsICJMc2VlayBzZXQgZmFpbGVkIik7Cglyc2l6ID0gcmVhZChpbmZk
LCBidWYsIDEwMjQgKiAxMDI0KTsKCWlmIChyc2l6IDwgMCkKCQllcnIoMSwgIlJlYWQgcmV0dXJu
ZWQgJWxkIiwgcnNpeik7CgljbG9zZShpbmZkKTsKCXJldHVybiAocnNpeik7Cn0KCmludAptYWlu
KGludCBhcmdjLCBjaGFyICphcmd2W10pCnsKCW9mZl90IG9mZnBvczsKCXNzaXplX3QgcnM7Cglj
aGFyIGM7Cglib29sIHJlYWRzcDsKCglyZWFkc3AgPSBmYWxzZTsKCXdoaWxlICgoYyA9IGdldG9w
dChhcmdjLCBhcmd2LCAicyIpKSAhPSAtMSkKCQlzd2l0Y2ggKGMpIHsKCQljYXNlICdzJzoKCQkJ
cmVhZHNwID0gdHJ1ZTsKCQkJYnJlYWs7CgkJZGVmYXVsdDoKCQkJZXJyeCgxLCAiQmFkIG9wdGlv
biAlYyIsIGMpOwoJCX0KCWFyZ3YgKz0gb3B0aW5kOwoJYXJnYyAtPSBvcHRpbmQ7CglpZiAoYXJn
YyAhPSAxKQoJCWVycngoMSwgIlVzYWdlOiByZWFkc3BhcnNlIDxpbmZpbGU+Iik7CglvZmZwb3Mg
PSAwOwoJZG8gewoJCWlmIChyZWFkc3ApCgkJCXJzID0gcmVhZHNwMW0oYXJndlswXSwgb2ZmcG9z
KTsKCQllbHNlCgkJCXJzID0gcmVhZDFtKGFyZ3ZbMF0sIG9mZnBvcyk7CgkJb2ZmcG9zICs9IDEw
MjQgKiAxMDI0OwoJfSB3aGlsZSAocnMgPiAwKTsKfQo=
--_003_YQXPR01MB4150BC25A9767E42251730DFDD7B9YQXPR01MB4150CANP_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR01MB4150BC25A9767E42251730DFDD7B9>