From owner-svn-src-all@FreeBSD.ORG Mon Apr 18 20:38:33 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4EC61065670; Mon, 18 Apr 2011 20:38:33 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2836D8FC0C; Mon, 18 Apr 2011 20:38:32 +0000 (UTC) Received: by wwc33 with SMTP id 33so6080316wwc.31 for ; Mon, 18 Apr 2011 13:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FJY3xesls86/dYyw1S/r6u7CLlMqOdyqgMAA2l47ZfI=; b=Y2KODYXDO+Hi9JlUjLbOmWbQrborouAPZMmZGbs0It3/XjaS3gSzeOcA+Ltcd/KckG 3oXkoP3CDuCkNrGeZeer4N/6uOuSgaWDbDQjdh1nzNXuIsNg9m60gn4iVudBu8PO04nx OplJMm3WLmjI75yT/sBweaecgQcNt5CBy3VuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UiT6jqH2ta/6uYSKCDzTvTeZdNSRXpIedu1QsXXBkxyv4dcgiheRlDz8VMfhsHz5Z3 rSSkKiZoJ8t2hyouT1BJWygcXD5CKrKiz/e3yM1PHcSEr4G9NACGQW+ezsw7dQALV7RJ 8ZtSYXSmzJj2DjXOGu2zvrayxgVUaJQL++Jeg= MIME-Version: 1.0 Received: by 10.216.134.207 with SMTP id s57mr5388644wei.25.1303159112166; Mon, 18 Apr 2011 13:38:32 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.9.67 with HTTP; Mon, 18 Apr 2011 13:38:32 -0700 (PDT) In-Reply-To: <20110418201302.GY48734@deviant.kiev.zoral.com.ua> References: <201104181632.p3IGWM5v077720@svn.freebsd.org> <20110418192810.GX48734@deviant.kiev.zoral.com.ua> <20110418201302.GY48734@deviant.kiev.zoral.com.ua> Date: Mon, 18 Apr 2011 13:38:32 -0700 X-Google-Sender-Auth: ZTAnSJErVqYWo5yaUuKdifcJtjo Message-ID: From: mdf@FreeBSD.org To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r220791 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:38:34 -0000 2011/4/18 Kostik Belousov : > On Mon, Apr 18, 2011 at 12:49:38PM -0700, mdf@freebsd.org wrote: >> On Mon, Apr 18, 2011 at 12:28 PM, Kostik Belousov = wrote: >> > On Mon, Apr 18, 2011 at 04:32:22PM +0000, Matthew D Fleming wrote: >> >> Author: mdf >> >> Date: Mon Apr 18 16:32:22 2011 >> >> New Revision: 220791 >> >> URL: http://svn.freebsd.org/changeset/base/220791 >> >> >> >> Log: >> >> =A0 Add the posix_fallocate(2) syscall. =A0The default implementation= in >> >> =A0 vop_stdallocate() is filesystem agnostic and will run as slow as = a >> >> =A0 read/write loop in userspace; however, it serves to correctly >> >> =A0 implement the functionality for filesystems that do not implement= a >> >> =A0 VOP_ALLOCATE. >> >> >> >> =A0 Note that __FreeBSD_version was already bumped today to 900036 fo= r any >> >> =A0 ports which would like to use this function. >> >> >> >> =A0 Also reserve space in the syscall table for posix_fadvise(2). >> The need is, as commented, to return EFBIG when the new file size will >> be larger than the FS supports. =A0Without this code, passing in >> something like posix_fallocate(fd, 0, OFF_MAX) will run the filesystem >> out of space. > Handling max file size and not overflowing the fs are different things. > VOP_WRITE() will handle file size on its own too. I see no problem with > exhausting free space if this is what user asked for. This violates the standard, though, since it would return ENOSPC instead of EFBIG. Also, this is just the default implementation. I'm adding a second VOP_SETATTR in vop_stdallocate() to restore the file size after extending, which will let the implementation use bzero/VOP_WRITE instead of VOP_READ/VOP_WRITE when past the original EOF. This is more of an issue when calling the vop iteratively, since subsequent calls don't know what the "correct" file size is. Cheers, matthew