| 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@xxxxxxxxxxxx> |
| References: | <200405121300.14866.stevew@xxxxxxxxxxxxxxx> <1084332608.11308.3.camel@noodles> <20040512143941.A389759@xxxxxxxxxxxxxxxxxxxxxxxx> <200405121618.27843.ncunningham@xxxxxxxxxxxxx> <20040512165624.C389759@xxxxxxxxxxxxxxxxxxxxxxxx> <20040512130047.A28089@xxxxxxxxxxxxx> <40C0D621.2010001@xxxxxxxxxxxx> |
| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: XFS for postgres databases?, Jeffrey W. Baker |
|---|---|
| Next by Date: | Re: Scan after crash, Eric Sandeen |
| Previous by Thread: | Re: XFS for postgres databases?, Jeremy Jackson |
| Next by Thread: | Re: XFS for postgres databases?, Olaf Frączyk |
| Indexes: | [Date] [Thread] [Top] [All Lists] |