From owner-freebsd-fs@freebsd.org Mon Feb 1 20:14:32 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA258A9855D for ; Mon, 1 Feb 2016 20:14:32 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 390361436 for ; Mon, 1 Feb 2016 20:14:32 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x233.google.com with SMTP id p63so87926000wmp.1 for ; Mon, 01 Feb 2016 12:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2S9Lqhbhw9s88rna0py4JdnB83J/FRWCED/VQFHXUsc=; b=NZxClzpqxu+Hmu7BU9OA+y6FsHfA44qh9zmF4ZKu89QyAqvoWx/odO3AEGcXXhWSZp AIAw+gOy1d0uGbgRG1PrBedCrhonf8wodal9EAhZ7xrkokKb0qeqM6AL987+QlaL+/hW iJZwZgUUJ/tuwWXaqM+xw7nkPUaPvGVYt0VerE4ymAGS8XQgWtyQc3CnT4jKWH8QPyOe 9gmumxgwwgC+DH1z1CZNfwVPbbM9LJ/bICiNZVYhxtwdE++0/bu+0d7ttwygt3A5NfSq iU4WOvdX2/OyIeEqxqdLkj2ONgmJNPDWLJw1yXtKRkX8Np1JCuHB3mp8kFdfJCk8/edF h9eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2S9Lqhbhw9s88rna0py4JdnB83J/FRWCED/VQFHXUsc=; b=VTBztX9NoxBvpkD3Jaropsyc/OjXp9lzQ3zFbNAWbTFbotppUvK8jlm1HuAJxIWgP1 kaKdSgk6nOOvaPzj0jQQDGom08yo1C3XAypXcSP5EBCqDQCpVVhM8SI/G+aMv0pa/Qey 2Jpd2FToKsyqJ1872glWHcMgj+GGjfBMw6xc0G+O/GQGfxT2ZZM7HUBQtFlT6IZGr0Xu Beg3EuCelrvGjjiIcG23nQVjiJiTyBm0ti/yZFVRpsCBDBiXDjn5F9BeNbfkjTP4lk+J Z0uw8f9+GmHmOsTuuP7svmoRm86qPv4KFyQITVoE8qzgKao3dKzolHeqdqS5ndZqOaLE ZGUw== X-Gm-Message-State: AG10YOSscBsDydTK3BUU2V/c1z2D43d9C7UylXPZtE8YSXQ1yXQaTITsriPXqDEB9TcpbVeWGAGmKU2W4HOOszTn MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr24198432wjc.137.1454357670726; Mon, 01 Feb 2016 12:14:30 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.39.195 with HTTP; Mon, 1 Feb 2016 12:14:30 -0800 (PST) In-Reply-To: <20160201194014.GQ91220@kib.kiev.ua> References: <20160201165648.GM91220@kib.kiev.ua> <20160201182257.GN91220@kib.kiev.ua> <20160201194014.GQ91220@kib.kiev.ua> Date: Mon, 1 Feb 2016 12:14:30 -0800 X-Google-Sender-Auth: g4RrwPqnFy1djucb__5Mm7Kud-U Message-ID: Subject: Re: Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA) From: Maxim Sobolev To: Konstantin Belousov Cc: freebsd-fs@freebsd.org, Kirk McKusick Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 20:14:32 -0000 Yeah, I've noticed that text now. It looks a lot like the sentence has been copied around and some part of it had lost in transition. In any case here is a small manpage patch to make a "vurtual hole" more pronounced and also explain how it affects return value of the syscall. https://reviews.freebsd.org/D5162 On Mon, Feb 1, 2016 at 11:40 AM, Konstantin Belousov wrote: > On Mon, Feb 01, 2016 at 11:22:18AM -0800, Maxim Sobolev wrote: > > Well, it's still seems to be quite obscure. At the very least, the > lseek(2) > > manual page needs to reflect that. Right now it says: > > > > ERRORS > > [...] > > [ENXIO] For SEEK_DATA, there are no more data regions > past > > the > > supplied offset. For SEEK_HOLE, there are no > more > > holes past the supplied offset. > > > > Which is not true, the SEEK_HOLE would return st_size when there are no > > more holes past the supplied offset, not ENXIO. It is also interesting > that > > somehow empty file is a special case as well. Both SEEK_HOLE and > SEEK_DATA > > return -1 on those. Anybody who programs to that document would probably > > get as confused as myself. > > > > However, having said that, our cousin Linux behaves the same - i.e. > returns > > EOF+1 on SEEK_HOLE and -1 on SEEK_DATA, and does the same for empty > files, > > so at least we are consistent with that. > > Actually, since you referred to the man page for lseek(2), which seems to > be copied from the Solaris man page: > ... > The existence of a hole at the end of every data region allows for easy > programming and implies that a virtual hole exists at the end of the > file. > ... > > And, the text you quoted, does not imply that the call must return ENXIO > at the EOF for hole. It only allows the call to do it, but other language > makes this unreasonable. > > Note that it is Solaris, not Linux, which implementation of the SEEK_HOLE > and SEEK_DATA is the arbitration sample for the behavior. We got it with > the ZFS import. Our UFS implementation, and whatever Linux does, are only > reimplementation without clean documentation, and were done by observing > ZFS behaviour. > >