xfs
[Top] [All Lists]

Re: xfs block size

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: xfs block size
From: Andi Kleen <ak@xxxxxxx>
Date: Wed, 17 Jan 2001 21:13:19 +0100
Cc: "Davida, Joe" <Joe_Davida@xxxxxxxxxx>, "'linux-xfs@xxxxxxxxxxx '" <linux-xfs@xxxxxxxxxxx>
In-reply-to: <20010117203852.B22384@xxxxxxxxxx>; from hch@xxxxxxxxxxxxx on Wed, Jan 17, 2001 at 08:38:52PM +0100
References: <09D1E9BD9C30D311919200A0C9DD5C2C025370A4@xxxxxxxxxxxxxxxxxxxxxxx> <20010117203852.B22384@xxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Wed, Jan 17, 2001 at 08:38:52PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 17, 2001 at 10:45:17AM -0700, Davida, Joe wrote:
> >     On the web page you sited, I read:
> > 
> > "...We are using pages to cache metadata, pages are
> > allocated one at a time, so each page sized chunk
> > of memory usually is not adjacent in the address
> > space to the page covering the next block of the
> > disk."
> > 
> >     How does FreeBSD's UFS let you mkfs filesystems
> >     with 16K FS pagesize? It is on same X86 architecture
> >     as Linux!
> 
> But it is not Linux.  They do organize things differently.
> (Linux UFS support larger blocks too, but it seems pretty b0rken
> currently)

iirc one of the plans for 2.5 is to move to bigger logical (and physical on
systems that support it like ia64) page sizes similar to Irix. Hopefully that 
will help XFS too. 

vmalloc got a bit cheaper in 2.4 now, no ipi needed on alloc anymore, just on
free, but it's probably still not a real option for any regular executed path. 


-Andi

<Prev in Thread] Current Thread [Next in Thread>