From nobody Fri Aug 20 15:33:24 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5D2B5176F625 for ; Fri, 20 Aug 2021 15:33:26 +0000 (UTC) (envelope-from khng@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Grlyt2DfHz4XXf for ; Fri, 20 Aug 2021 15:33:26 +0000 (UTC) (envelope-from khng@FreeBSD.org) Received: from Kas-MacBook-Pro.local (unknown [IPv6:2001:470:f816:0:1a9:413f:d3c5:1c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: khng/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id CBC2CB6CA for ; Fri, 20 Aug 2021 15:33:25 +0000 (UTC) (envelope-from khng@FreeBSD.org) Subject: Re: fspacectl(2): result of rmsr.r_offset for a success and non-partial operation From: Ka Ho Ng To: freebsd-fs@FreeBSD.org References: <87d4a87d-2ee3-74dd-3689-94dc0daf3983@FreeBSD.org> Message-ID: <29087ddc-9b46-15fa-4041-c3a50dcf99db@FreeBSD.org> Date: Fri, 20 Aug 2021 23:33:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 In-Reply-To: <87d4a87d-2ee3-74dd-3689-94dc0daf3983@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 2021/8/20 11:23 PM, Ka Ho Ng wrote: > There were some recent discussion in https://reviews.freebsd.org/D31604 > around the returned value of rmsr.r_offset. For a complete and > successful operation, rmsr.r_len is set to 0. Regarding rmsr.r_offset, > the bottom line is to have rmsr.r_offset being no greater than current > file size in case rmsr.r_offset is greater than file size, while leaving > rmsr.r_offset to be within EOF in case rqsr.r_offset is not beyond EOF. > > With the current approach, rmsr.r_offset is loosely defined as file > system is free to set it to some value as long as it is neither smaller > than rqsr.r_offset (in case rqsr.r_offset is within EOF), or beyond EOF > (in case rqsr.r_offset is beyond EOF). Do you think it is a good idea to > make it stricter in case the call succeeds and rmsr.r_len == 0 (i.e. a > complete operation)? If that is the case, what if we set rmsr.r_offset > to be rqsr.r_offset + rqsr.r_len? > > Ka Ho > My another approach is to explicitly document that for a complete and successful operation (i.e. rmsr.r_len == 0) callers need not to consider the exact value of rmsr.r_offset, except if the operation range is not complete outside of EOF, rmsr.r_offset is not going to be outside of EOF either. Ka Ho