On Wed, Sep 19, 2007 at 03:06:20PM -0700, Matthew Ahrens wrote:
> Pawel Jakub Dawidek wrote:
> > On Tue, Aug 07, 2007 at 11:28:31PM +0100, James Blackburn wrote:
> >> Well I read this email having just written a mammoth one in the other
> >> thread, my thoughts:
> >>
> >> The main difficulty in thi
Pawel Jakub Dawidek wrote:
> On Tue, Aug 07, 2007 at 11:28:31PM +0100, James Blackburn wrote:
>> Well I read this email having just written a mammoth one in the other
>> thread, my thoughts:
>>
>> The main difficulty in this, as far as I see it, is you're
>> intentionally moving data on a checksumm
On 9/12/07, Pawel Jakub Dawidek wrote:
> On Tue, Aug 07, 2007 at 11:28:31PM +0100, James Blackburn wrote:
> > Well I read this email having just written a mammoth one in the other
> > thread, my thoughts:
> >
> > The main difficulty in this, as far as I see it, is you're
> > intentionally moving d
On Tue, Aug 07, 2007 at 11:28:31PM +0100, James Blackburn wrote:
> Well I read this email having just written a mammoth one in the other
> thread, my thoughts:
>
> The main difficulty in this, as far as I see it, is you're
> intentionally moving data on a checksummed copy-on-write filesystem
> ;).
Well I read this email having just written a mammoth one in the other
thread, my thoughts:
The main difficulty in this, as far as I see it, is you're
intentionally moving data on a checksummed copy-on-write filesystem
;). At the very least this is creating lots of work before we even
start to add
Yeah:)
I'd like to work on this. Here are my first observations:
- We need to call vdev_op_asize method with additonal 'offset' argument,
- We need to move data to new disk starting from the very begining, so
we can't reuse scrub/resilver code which does tree-walk through the
data.
Below you