From owner-freebsd-arch@FreeBSD.ORG Sat Oct 29 00:36:57 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AFCC106564A; Sat, 29 Oct 2011 00:36:57 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 2CC3E8FC22; Sat, 29 Oct 2011 00:36:57 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p9T0augE016455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Oct 2011 17:36:57 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p9T0ausS016454; Fri, 28 Oct 2011 17:36:56 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA05044; Fri, 28 Oct 11 17:25:57 PDT Date: Sat, 29 Oct 2011 00:24:32 -0700 From: perryh@pluto.rain.com To: jhb@freebsd.org Message-Id: <4eabaa30.DY7ebNVKU5sQEFsY%perryh@pluto.rain.com> References: <201110281426.00013.jhb@freebsd.org> In-Reply-To: <201110281426.00013.jhb@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call 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: Sat, 29 Oct 2011 00:36:57 -0000 John Baldwin wrote: > I have been working for the last week or so on a patch to add an > fadvise(2) system call. It is somewhat similar to madvise(2) > except that it operates on a file descriptor instead of a memory > region. It also only really makes sense for regular files and > does not apply to other file descriptor types. Seems to me it could also make sense for disks and geoms. The access patterns used by dump(8) and fsck(8) are likely different, from each other and from those typically encountered in the course of filesystem activity -- and I wouldn't be surprised if mounted access patterns tended to differ among, say, ufs, zfs, and msdosfs. Granted the pattern of disk activity created by a filesystem will vary greatly, depending on the patterns of file access that the filesystem is servicing.