From owner-freebsd-arch@FreeBSD.ORG Thu Apr 14 22:41:32 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98F70106566B; Thu, 14 Apr 2011 22:41:32 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 08D118FC15; Thu, 14 Apr 2011 22:41:31 +0000 (UTC) Received: by wyf23 with SMTP id 23so2177724wyf.13 for ; Thu, 14 Apr 2011 15:41:31 -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=sJlFQlEaz2BWsKmn00+seKx0+qvIhWtlCbWauJsHf/c=; b=LdmCbq4UzM3D0Qp9DsjQuyK7wKfRTnbTeIPi0YOAa+bE5sygrvdcqskO0BSap+y76l yVK2SQWeD3+sPDxsgctbwDP+DTZtQ2mpWmsfRr79/yCzh/sNlk54lsclhrawModwAYak AoB6VDYXzrD33519RyJ/TTicDIMYSosS5J+Wk= 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=fVPCL9CqxiAhwDVU5/h+SRZ6QkpZnsSmnvAt8qqG/oi7ATWJk91yGlyap29yyCOzpy jWzpj63UCtHdKRoqNhJjouQc5A/W9I5nhnj3pArRSTRj/dRx2uW4EIBJqUj0Cdoi+0z/ k/qDrud+8lgy2i9bi8VA/TGDxJWPY7mUhABTo= MIME-Version: 1.0 Received: by 10.216.254.142 with SMTP id h14mr1335515wes.31.1302820890662; Thu, 14 Apr 2011 15:41:30 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.123.15 with HTTP; Thu, 14 Apr 2011 15:41:30 -0700 (PDT) In-Reply-To: <20110414213610.GB92382@tops> References: <20110414213610.GB92382@tops> Date: Thu, 14 Apr 2011 15:41:30 -0700 X-Google-Sender-Auth: WGdARzJ-7PlNT0Ql2IBqAAl84lU Message-ID: From: mdf@FreeBSD.org To: Gleb Kurtsou , John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch Subject: Re: posix_fallocate(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 22:41:32 -0000 On Thu, Apr 14, 2011 at 2:36 PM, Gleb Kurtsou wrot= e: > On (14/04/2011 12:35), mdf@FreeBSD.org wrote: >> For work we need a functionality in our filesystem that is pretty much >> like posix_fallocate(2), so we're using the name and I've added a >> default VOP_ALLOCATE definition that does the right, but dumb, thing. >> >> The most recent mention of this function in FreeBSD was another thread >> lamenting it's failure to exist: >> http://lists.freebsd.org/pipermail/freebsd-ports/2010-February/059268.ht= ml >> >> The attached files are the core of the kernel implementation of the >> syscall and a default VOP for any filesystem not supporting >> VOP_ALLOCATE, which allows the syscall to work as expected but in a >> non-performant manner. =A0I didn't see this syscall in NetBSD or >> OpenBSD, so I plan to add it to the end of our syscall table. >> >> What I wanted to check with -arch about was: >> >> 1) is there still a desire for this syscall? > It looks not to play well architecturally with modern COW file systems > like ZFS and HUMMER. So potentially it can be implemented only for UFS. The syscall, or the dumb implementation? I don't see why the syscall itself would be a problem; presumably ZFS can figure out whether an fallocate() block is worth COWing or not... >> 2) is this naive implementation useful enough to serve as a default >> for all filesystems until someone with more knowledge fills them in? > Maillist ate the patch. Only man page attached. Whoops! http://people.freebsd.org/~mdf/bsd-fallocate.diff Cheers, matthew