|Pawel Jakub Dawidek||Jun 19, 2006 1:13 pm|
|Niki Denev||Jun 19, 2006 6:32 pm|
|Brooks Davis||Jun 19, 2006 6:57 pm|
|Craig Rodrigues||Jun 20, 2006 6:35 am|
|Pawel Jakub Dawidek||Jun 20, 2006 8:38 am|
|Pawel Jakub Dawidek||Jun 20, 2006 8:43 am|
|Alex Dupre||Jun 20, 2006 9:05 am|
|Pawel Jakub Dawidek||Jun 20, 2006 9:14 am|
|Phil Regnauld||Jun 20, 2006 10:28 am|
|Mike Jakubik||Jun 20, 2006 7:20 pm|
|Pawel Jakub Dawidek||Jun 20, 2006 7:38 pm|
|Xin LI||Jun 20, 2006 7:59 pm|
|Mike Jakubik||Jun 20, 2006 8:07 pm|
|Bakul Shah||Jun 20, 2006 8:29 pm|
|Scott Long||Jun 20, 2006 8:32 pm|
|Ulrich Spoerlein||Jun 20, 2006 8:49 pm|
|Pawel Jakub Dawidek||Jun 20, 2006 8:52 pm|
|Bruce Evans||Jun 21, 2006 3:30 pm|
|Pawel Jakub Dawidek||Jun 22, 2006 9:49 am|
|Pawel Jakub Dawidek||Jun 22, 2006 9:55 am|
|Pawel Jakub Dawidek||Jun 22, 2006 10:08 am|
|Alexandr Kovalenko||Jun 23, 2006 8:22 am|
|R. B. Riddick||Jun 23, 2006 8:38 am|
|Alexandr Kovalenko||Jun 23, 2006 8:53 am|
|Eric Anderson||Jun 23, 2006 3:20 pm|
|Pawel Jakub Dawidek||Jun 23, 2006 7:42 pm|
|Peter Jeremy||Jun 23, 2006 7:49 pm|
|Subject:||Journaling UFS with gjournal.|
|From:||Bakul Shah (bak...@bitblocks.com)|
|Date:||Jun 20, 2006 8:29:29 pm|
This is great! We have sorely needed this for quite a while what with terabyte size filesystems getting into common use.
How it works (in short). You may define one or two providers which gjournal will use. If one provider is given, it will be used for both - data and journal. If two providers are given, one will be used for data and one for journal. Every few seconds (you may define how many) journal is terminated and marked as consistent and gjournal starts to copy data from it to the data provider. In the same time new data are stored in new journal.
Some random comments:
Would it make sense to treat the journal as a circular buffer? Then commit to the underlying provider starts when the buffer has $hiwater blocks or the upper layer wants to sync. The commit stops when the buffer has $lowater blocks or in case of sync the buffer is empty. This will allow parallel writes to the provider and the journal, thereby reducing latency.
I don't understand why you need FS synchronization. Once the journal is written, the data is safe. A "redo" may be needed after a crash to sync the filesystem but that is about it. Redo should be idempotent. Each journal write block may need some flags. For instance mark a block as a "sync point" -- when this block is on the disk, the FS will be in a consistent state. In case of redo after crash you have to throw away all the journal blocks after the last sync point.
It seems to me if you write a serial number with each data block, in the worst case redo has to do a binary search to find the first block to write but normal writes to journal and reads from journal (for commiting to the provider) can be completely sequential. Since redo will be much much faster than fsck you can afford to slow it down a bit if the normal case can be speeded up.
Presumably you disallow opening any file in /.deleted.
Can you gjournal the journal disk? Recursion is good:-)