Date: Mon, 12 Feb 2001 16:21:33 -0500 (EST) From: Zhiui Zhang <zzhang@cs.binghamton.edu> To: Russell Cattelan <cattelan@thebarn.com> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Design a journalled file system Message-ID: <Pine.SOL.4.21.0102121611230.14762-100000@opal> In-Reply-To: <3A884C91.56037FFE@thebarn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Feb 2001, Russell Cattelan wrote: > Zhiui Zhang wrote: > > > On Mon, 12 Feb 2001, Russell Cattelan wrote: > > > > > > Another difficulty is that if several transactions are in progress at the > > > > same time, we must remember which metadata buffers are modified by which > > > > transactions. When we copy/rename the buffer, we must inform those > > > > transactions the fact that we did the copy/rename. The buffers modified > > > > by one transaction must be flushed at the same time. > > > > Thanks for your reply. I mean if a transaction locks down all the metadata > > (e.g., bitmap blocks) it modified until it commits, then there is no > > problem (but this reduces concurrency). Otherwise, the same metadata > > blocks can contain modifications done by more than one transaction. > > This really isn't a problem... meta data buffers have to be "pinned" but not > necessarily locked. A meta data buffer can be modified many times without > having to be written out to disk, take for example the super block, this will > get flushed out to disk occasionally but since it is being modified so often > most changes never get flushed. A log of each of those changes will > be in every transaction that touched the super block, but the super > block doesn't have to be written out every time. > The primary goal is to have a consistent file system not to be able > to rollback every change that happens. > It seems to me that I have failed to explain my point again. So an example may help. Suppose I have a bitmap block buffer. One transaction allocate some blocks from it, the other transaction free some blocks into it. If the bitmap block buffer is not locked for the duration of a transaction, then it could contain modifications made both transactions. The atomicity is violated unless you can make the two transactions merge into one later. On the other hand, if it is locked for a transaction and that transaction blocks for some other I/O, then performance will suffer (no one can use the bitmap block buffer for a while). -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.4.21.0102121611230.14762-100000>