| To: | Russell Cattelan <cattelan@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: REVIEW: xfs_reno |
| From: | David Chinner <dgc@xxxxxxx> |
| Date: | Wed, 3 Oct 2007 09:41:27 +1000 |
| Cc: | David Chinner <dgc@xxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Barry Naujok <bnaujok@xxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>, xfs-dev <xfs-dev@xxxxxxx> |
| In-reply-to: | <470274BF.7070702@thebarn.com> |
| References: | <op.tzj549h63jf8g2@pc-bnaujok.melbourne.sgi.com> <20071002090216.GA22721@infradead.org> <20071002091951.GE995458@sgi.com> <470274BF.7070702@thebarn.com> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.4.2.1i |
On Tue, Oct 02, 2007 at 11:41:35AM -0500, Russell Cattelan 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... > > If we do that could be move to an inode based log? What do we gain from doing that? (I'm a bit slow today) > Keep it contagious so recovery won't have to parse > up the file system to find the log. I'm worried by those contagious logs. What do you catch from them? :) > The normal running case should be easier to deal with if > the log was just a file? I don't see how it changes anything - we address the log directly by block number and device... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: sync_blockdev in xfs_flush_device_work, David Chinner |
|---|---|
| Next by Date: | Re: REVIEW: xfs_reno, Barry Naujok |
| Previous by Thread: | Re: REVIEW: xfs_reno, Russell Cattelan |
| Next by Thread: | Re: REVIEW: xfs_reno, Barry Naujok |
| Indexes: | [Date] [Thread] [Top] [All Lists] |