| From | Sent On | Attachments |
|---|---|---|
| Zhiui Zhang | Feb 6, 2001 1:15 pm | |
| Sam Leffler | Feb 6, 2001 1:46 pm | |
| Alfred Perlstein | Feb 6, 2001 1:52 pm | |
| Zhiui Zhang | Feb 6, 2001 6:20 pm | |
| Terry Lambert | Feb 7, 2001 1:47 pm | |
| Jack Rusher | Feb 7, 2001 1:56 pm | |
| Terry Lambert | Feb 7, 2001 2:09 pm | |
| Terry Lambert | Feb 7, 2001 3:22 pm | |
| Zhiui Zhang | Feb 7, 2001 3:39 pm | |
| Russell Cattelan | Feb 8, 2001 11:05 pm | |
| Russell Cattelan | Feb 8, 2001 11:12 pm | |
| Terry Lambert | Feb 9, 2001 12:56 am | |
| Zhiui Zhang | Feb 9, 2001 9:24 am | |
| Russell Cattelan | Feb 9, 2001 10:08 am | |
| Karsten W. Rohrbach | Feb 9, 2001 11:23 am | |
| Russell Cattelan | Feb 9, 2001 11:37 am | |
| Julian Elischer | Feb 9, 2001 11:58 am | |
| Russell Cattelan | Feb 12, 2001 11:37 am | |
| Zhiui Zhang | Feb 12, 2001 12:34 pm | |
| Russell Cattelan | Feb 12, 2001 12:50 pm | |
| Zhiui Zhang | Feb 12, 2001 1:21 pm | |
| Terry Lambert | Feb 12, 2001 3:06 pm | |
| Zhiui Zhang | Feb 12, 2001 4:27 pm | |
| Russell Cattelan | Feb 12, 2001 4:49 pm | |
| Adrian Chadd | Feb 13, 2001 2:07 am | |
| Russell Cattelan | Feb 15, 2001 1:50 pm | |
| Robert Clark | Feb 20, 2001 7:27 pm | |
| Terry Lambert | Feb 20, 2001 8:03 pm | |
| Russell Cattelan | Feb 20, 2001 11:23 pm | |
| Daniel C. Sobral | Feb 26, 2001 3:51 am | |
| Terry Lambert | Feb 26, 2001 5:31 am | |
| Terry Lambert | Feb 26, 2001 5:34 am | |
| Jamie Bowden | Feb 26, 2001 7:35 am | |
| Bill Vermillion | Feb 26, 2001 9:55 am | |
| Daniel C. Sobral | Feb 26, 2001 11:17 am | |
| Brad Knowles | Feb 26, 2001 11:41 am | |
| Terry Lambert | Feb 26, 2001 7:42 pm | |
| Terry Lambert | Feb 26, 2001 7:46 pm | |
| Daniel O'Connor | Feb 26, 2001 7:51 pm | |
| Terry Lambert | Feb 26, 2001 8:06 pm | |
| Jonathan Lemon | Feb 26, 2001 8:11 pm | |
| Daniel O'Connor | Feb 26, 2001 8:12 pm | |
| Brett Glass | Feb 26, 2001 8:16 pm | |
| Terry Lambert | Feb 26, 2001 10:20 pm | |
| Daniel C. Sobral | Feb 27, 2001 12:29 am | |
| Doug Rabson | Feb 27, 2001 1:45 am | |
| Doug Rabson | Feb 27, 2001 1:46 am | |
| Jonathan Lemon | Feb 27, 2001 6:46 am | |
| Bill Vermillion | Feb 27, 2001 7:18 am | |
| Brad Knowles | Feb 27, 2001 9:48 am | |
| Peter Wemm | Feb 27, 2001 10:43 am | |
| Terry Lambert | Feb 27, 2001 11:44 am | |
| Terry Lambert | Feb 27, 2001 12:19 pm | |
| Rik van Riel | Feb 27, 2001 12:41 pm | |
| Terry Lambert | Feb 27, 2001 11:13 pm | |
| Russell Cattelan | Feb 28, 2001 3:49 pm | |
| Karsten W. Rohrbach | Mar 24, 2001 8:07 pm | |
| Coleman Kane | Mar 26, 2001 9:15 am | |
| Karsten W. Rohrbach | Mar 26, 2001 10:00 am |
| Subject: | Re: Design a journalled file system | |
|---|---|---|
| From: | Zhiui Zhang (zzh...@cs.binghamton.edu) | |
| Date: | Feb 12, 2001 12:34:32 pm | |
| List: | org.freebsd.freebsd-fs | |
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. I do not know how XFS solves this problem. Since XFS uses B+ tree, I guess that locking can be done in a hierarchy way easily to avoid deadlock. But in FFS, the bitmap blocks has no relationship with each other. Locking the bitmap blocks in FFS in arbitrary order can cause deadlock, I guess.
IBM JFS seems to use incore log implemented as page cache. XFS has pagebuf. I expect that is something similar to IBM's page cache.
Hmm I'm not sure what the problem is here. A transaction log entry will log all changes necessary to complete that transaction, even if it involves multiple meta data objects, which is almost always does. In the event of a crash and subsequent replay of the log: the recovery code will make sure all the meta data on the disk is consistent with the log. If one meta data write happened but the another one didn't the recovery code only updates the one that didn't complete.
What is the size of the disk block container on bsd buf_t's ? if they are 64bit we shouldn't have a problem... simply use absolution disk addressing for meta data items. Why would we need to copy a meta data buf_t?
In sys/buf.h of FreeBSD, it has:
daddr_t b_lblkno; /* Logical block number. */ daddr_t b_blkno; /* Underlying physical block number. */
Both are 32-bit integer. I am not sure why it is not 64-bit. Maybe it has something to do with merged buffer cache.
-Zhihui
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message





