#20 — resilvering continues after offlining device to be resilvered.

please retest with

# git clone http://git.zfs-fuse.net/official
# cd official/
# git checkout origin/critical

if at all possible. You can also merge the fixes since 0.6.0 from that branch

mail dd Sat, 19 Jun 2010 10:21:51 -0700

I just noticed some odd behaviour that I did not expect.

I tried a zfs send|zfs receive on my machine.
Then noticed that I did want to only send incremental data and canceled
the command with CTRL+C. So far so good.
I continued with the incremental data which worked out fine and tried to
export the target pool afterwards.

That did not work. Zpool claimed that the pool was still busy.
I checked to see that it was already unmounted. Then I noticed that
there was still I/O activity on the disk. According to iostat, it was
actually the full bandwidth that was possible for that disk.

The same happens with CTRL+C while doing a "zfs rollback". Activity
continues until the rollback is finished.

I noticed similar behaviour earlier while resilvering. In case the disk
that is being resilvered is suddlenly removed, heavy reading activity
continues on the source disk.

For the first case I would expect zfs to just cancel activity on both
the source and target pool. The same for cancelling a rollback.

If the target fails while resilvering, that should probably be detected...

I don't have solaris on any machine to test those cases there.
Does someone know what should really happen? Did someone else experience
these problems?

All the best,
Maximilian.


-- To post to this group, send email to zfs-fuse@googlegroups.com To visit our Web site, click on http://zfs-fuse.net/

 On 06/19/2010 07:21 PM, Maximilian Mehnert wrote:
> there was still I/O activity on the disk. According to iostat, it was
> actually the full bandwidth
Read or write?

> For the first case I would expect zfs to just cancel activity on both
> the source and target pool.
Agreed

> The same for cancelling a rollback.
>
Not agreed. I would expect ZFS to complete the currently running atomic transaction, and then abort the rollback. This could take some time, especially under e.g. dedup.

> I don't have solaris on any machine to test those cases there.
>
I do.

> Does someone know what should really happen?
Sun does :)

> Did someone else experience
> these problems?
>
No.

Mail dd. Sat, 19 Jun 2010 11:51:40 -0700 (PDT)

>> >> actually the full bandwidth
> > Read or write?
I'm not sure anymore. But it was definitely the disk with the receiving
pool.
If needed I'll try to reproduce it.

> > Can you state which versions these new report applies to.
commit 281dcc3aea76fa371a55af83869049bef159a9af
Author: Seth Heeren <sgheeren@hotmail.com>
Date: Thu Jun 3 21:06:11 2010 +0200

>> >> The same for cancelling a rollback.
> > Not agreed. I would expect ZFS to complete the currently running atomic
> > transaction, and then abort the rollback. This could take some time,
> > especially under e.g. dedup.
Agreed ;-)

> > Do you mean you
> > _know_ it detects it, or you just hope it will; do you have
> > anyparticular reason to mention it? If so, please share more details :)
Ok. I'll try. I've two devices in a raidz pool. Both via device mapper.
Let's say /dev/mapper/part1, /dev/mapper/part2.
part1 is ok and part2 ist resilvering. When part2 is unplugged, zpool
status shows an ongoing resilvering process. Read activity on part1
continues (I guess till the end of the supposed resilvering process.
Never waited that long).

Yet another very loose thought:

/etc/profile
/etc/profile.d/*
~/.profile

/etc/bash.bashrc
~/.bashrc
/etc/environment

check to see if anywhere it contains "trap 2 3" or something similar?