xfs
[Top] [All Lists]

Re: REVIEW: xfs_reno

To: David Chinner <dgc@xxxxxxx>
Subject: Re: REVIEW: xfs_reno
From: Timothy Shimmin <tes@xxxxxxx>
Date: Wed, 03 Oct 2007 11:30:53 +1000
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Barry Naujok <bnaujok@xxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>
In-reply-to: <20071002091951.GE995458@xxxxxxx>
References: <op.tzj549h63jf8g2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20071002090216.GA22721@xxxxxxxxxxxxx> <20071002091951.GE995458@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
David Chinner wrote:
At that point, we'll got a "working" shrink that will allow
shrinking to only 50% of the original size because the log will
get in the way. To fix that, we'll need to implement transactions
to move the log...

Moving the log sounds pretty tricky.

Either we'd need to clean out the log (a la freeze) or
copy the active part (tail->head) to the new location and zero out the rest of
the new log space (or may even need to write sectors with
previous cycle#s at the start of each sector for the rest).
So how would one do that with the copying approach because
we'd need to be writing in to the new log and we'd need the log
pointer in the superblock to be logged somewhere ughhhh.
I think a type of freezing may be the way to go.
The trouble is we need to point the sb to the new log and the
only place to log that is in the old log.
So I guess before unfreezing you write the sb logptr change
using the old log and then after the unfreeze, everything uses the new log.
If you die before the sb change to disk then on mount you replay the sb change
using the old log and then start writing to the new log. If you die before 
writing the
sb change in the old log then you are stuck.
You need this log change and freespace change (for making room for the log)
in a transaction together and probably with other stuff.
Okay, I'm getting lost :)

--Tim


<Prev in Thread] Current Thread [Next in Thread>