xfs
[Top] [All Lists]

Re: XFS for postgres databases?

To: Jeremy Jackson <jerj@xxxxxxxxxxxx>
Subject: Re: XFS for postgres databases?
From: Steve Lord <lord@xxxxxxx>
Date: Fri, 04 Jun 2004 15:12:24 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Nathan Scott <nathans@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <40C0D621.2010001@coplanar.net>
References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <20040512143941.A389759@wobbly.melbourne.sgi.com> <200405121618.27843.ncunningham@linuxmail.org> <20040512165624.C389759@wobbly.melbourne.sgi.com> <20040512130047.A28089@infradead.org> <40C0D621.2010001@coplanar.net>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 0.6 (X11/20040502)
Jeremy Jackson wrote:
Is there anything in the new 2.6 bio and queueing code that could replace pagebufs entirely? That would seem ideal.

They are at a different level, bio's are a mechanism for reading and writing from block devices, pagebufs are the units of caching and locking metadata in xfs. Pagebufs are pushed on and off disk using bio's in 2.6

The tricky part of xfs on linux is that not all the metadata
is the same size, and some is larger than a page. xfs needs to
be able to lock metadata, prevent it from being flushed to
disk at certain times, and look it up in these chunks rather
than in pages or in even subunits of a page. This is why
pagebuf exists.

Note that the blockdev mapping and the xfs metadata are the same
memory, its just they do not cooperate on the locking correctly,
so if you access both at once, you end up trashing on or the other.

Steve



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