On 05/24/2011 11:56 PM, liubo wrote:
The problems I hit:
When an inode is dropped from cache (just via iput) and then read in
again, the BTRFS_I(inode)-logged_trans goes back to zero. When this
happens the logging code assumes the inode isn't in the log and hits
-EEXIST if it finds
Excerpts from liubo's message of 2011-05-25 06:21:04 -0400:
On 05/24/2011 11:56 PM, liubo wrote:
The problems I hit:
When an inode is dropped from cache (just via iput) and then read in
again, the BTRFS_I(inode)-logged_trans goes back to zero. When this
happens the logging code
On 05/24/2011 11:56 PM, liubo wrote:
Second, we use the generation number of the super to read in the log
tree root after a crash. This doesn't always match the sub trans id and
so it doesn't always match the transid stored in the btree blocks.
There are a few solutions to this, we
Excerpts from Chris Mason's message of 2011-05-19 20:23:29 -0400:
Excerpts from Liu Bo's message of 2011-05-19 04:11:24 -0400:
Introduce a new concept sub transaction,
the relation between transaction and sub transaction is
transaction A --- transid = x
sub trans a(1) ---
On 05/23/2011 10:40 AM, Chris Mason wrote:
Excerpts from Chris Mason's message of 2011-05-19 20:23:29 -0400:
Excerpts from Liu Bo's message of 2011-05-19 04:11:24 -0400:
Introduce a new concept sub transaction,
the relation between transaction and sub transaction is
transaction A ---
On 05/20/2011 08:23 AM, Chris Mason wrote:
Excerpts from Liu Bo's message of 2011-05-19 04:11:24 -0400:
Introduce a new concept sub transaction,
the relation between transaction and sub transaction is
transaction A --- transid = x
sub trans a(1) --- sub_transid = x+1
sub trans
