From owner-freebsd-hackers Fri May 21 9:19: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles521.castles.com [208.214.165.85]) by hub.freebsd.org (Postfix) with ESMTP id 546B31566C for ; Fri, 21 May 1999 09:19:02 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id JAA00959; Fri, 21 May 1999 09:16:35 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199905211616.JAA00959@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mark Newton Cc: pasha@sim.net.ua (Pavel Narozhniy), freebsd-hackers@FreeBSD.ORG Subject: Re: Source code of SGI XFS In-reply-to: Your message of "Sat, 22 May 1999 00:21:54 +0930." <199905211451.AAA74303@gizmo.internode.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 May 1999 09:16:34 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Pavel Narozhniy wrote: > > > Does anybody heard about SGI releasing XFS source code? > > Yup, they're doing it. > > I would guess that FreeBSD would need a fairly thorough revamp of its > handling of kernel memory allocation before XFS would be fully usable, > though: XFS buffer management is pretty full-on. Read "Irix has shitty block I/O support so XFS has to do it all itself". > The filesystem maintains its own pool of kernel buffers separate from > the VM page cache which it uses for aggregating I/O transfers (so that > if, say, you make 5 separate out-of-order I/Os which just happen to > blanket a contiguous region of a disk object, XFS will collapse them > into a single I/O; We do this too; it's called I/O clustering, but it's done below the filesystem so that anyone and everyone can benefit from it. > it'll also take small contiguous regions (extents) > and remap them into the next-power-of-two extent size as they grow. Whatever that means. 8) > I know I could probably see by looking at the source, but does FreeBSD > still impose a 64k limit on physical I/O operations? That'll have > to go too... Nominally. We ought to be able to support fragmentation as required to support the underlying device, but it's not complete yet. The fixes are relatively trivial. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message