From nobody Fri Aug 20 15:23:57 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 B5405176E75D for ; Fri, 20 Aug 2021 15:24:00 +0000 (UTC) (envelope-from khng@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4Grlm04q4dz4W1m for ; Fri, 20 Aug 2021 15:24:00 +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 1D557B6C0 for ; Fri, 20 Aug 2021 15:23:59 +0000 (UTC) (envelope-from khng@FreeBSD.org) To: freebsd-fs@FreeBSD.org From: Ka Ho Ng Subject: fspacectl(2): result of rmsr.r_offset for a success and non-partial operation Message-ID: <87d4a87d-2ee3-74dd-3689-94dc0daf3983@FreeBSD.org> Date: Fri, 20 Aug 2021 23:23:57 +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 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N 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