Messages in this thread | | | Date | Mon, 04 Mar 2002 13:41:21 -0500 | From | Chris Mason <> | Subject | Re: [PATCH] 2.4.x write barriers (updated for ext3) |
| |
On Monday, March 04, 2002 12:11:27 PM -0600 James Bottomley <James.Bottomley@steeleye.com> wrote:
> mason@suse.com said: >> Sorry, what do you mean by multi-threaded back end completion of the >> transaction? > > It's an old idea from databases with fine grained row level locking. To alter > data in a single row, you reserve space in the rollback log, take the row > lock, write the transaction description, write the data, undo the transaction > description and release the rollback log space and row lock. These actions > are sequential, but there may be many such transactions going on in the table > simultaneously. The way I've seen a database do this is to set up the actions > as linked threads which are run as part of the completion routine of the > previous thread. Thus, you don't need to wait for the update to complete, you > just kick off the transaction.
Ok, then, like sct said, we try really hard to have external threads do log io for us. It also helps that an atomic unit usually isn't as small as 'mkdir p'. Many operations get batched together to reduce log overhead.
-chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |