Date: Wed, 18 Aug 2021 00:00:02 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Ka Ho Ng <khng@freebsd.org> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: fspacectl(2) questions Message-ID: <YQXPR0101MB09687CC84880885AC7EADD41DDFE9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
First off, thanks for doing this. I am just implementing the NFSv4.2=0A=
Deallocate operation using it. (I'll put the patches up on phabricator=0A=
soon.)=0A=
=0A=
There are a couple of things I've spotted during testing.=0A=
1 - If you specify (for example):=0A=
rqst.r_offset =3D 65536=0A=
rqst.r_len =3D 1048576=0A=
and then use these to do a fspacectl(fd, SPACECTL_DEALLOC, &rqst, 0=
, &rqst)=0A=
on a file < 1048576 bytes in length, it works and zeros out 65536->EOF,=
=0A=
which is what I would have expected.=0A=
However, rqst.r_offset is set to 1114112 after the syscall.=0A=
Is that intended? I just thought it was a little weird to return r_offse=
t > EOF instead=0A=
of the size of the file.=0A=
If that is the intended behaviour, I'm fine with that, but maybe "man fs=
pacectl"=0A=
should indicate that? Maybe something like "bytes beyond EOF in the spec=
ified=0A=
range will not be set to zero (ie. file size not increased), but that r_=
offset will be=0A=
advanced to the end of the range, even if beyond EOF".=0A=
=0A=
2 - Setting=0A=
rqst.r_offset =3D OFF_MAX=0A=
rqst.r_len =3D 65536=0A=
results in an EINVAL errno, which seems fine, but isn't mentioned in t=
he=0A=
man page.=0A=
=0A=
But overall, works fine for me. (Of course, it will be nice when UFS and ZF=
S=0A=
get VOP_DEALLOCATE() calls that really deallocate.)=0A=
=0A=
Again, thanks for doing this, rick=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB09687CC84880885AC7EADD41DDFE9>