Hi Gary,
I will file a bug to track the zfs upgrade/device busy problem.
We use beadm or lucreate to upgrade the root BE so we generally don't
have to do an in-place root dataset replacement.
Thanks,
Cindy
On 07/29/10 17:03, Gary Mills wrote:
On Thu, Jul 29, 2010 at 10:26:14PM +0200, Pawel Jakub Dawidek wrote:
On Thu, Jul 29, 2010 at 12:00:08PM -0600, Cindy Swearingen wrote:
I found a similar zfs upgrade failure with the device busy error, which
I believe was caused by a file system mounted under another file system.
If this is the cause, I will file a bug or find an existing one.
No, it was caused by processes active on those filesystems.
The workaround is to unmount the nested file systems and upgrade them
individually, like this:
# zfs upgrade space/direct
# zfs upgrade space/dcc
Except that I couldn't unmount them because the filesystems were busy.
'zfs upgrade' unmounts file system first, which makes it hard to upgrade
for example root file system. The only work-around I found is to clone
root file system (clone is created with most recent version), change
root file system to newly created clone, reboot, upgrade original root
file system, change root file system back, reboot, destroy clone.
In this case it wasn't the root filesystem, but I still had to disable
twelve services before doing the upgrade and enable them afterwards.
`fuser -c' is useful to identify the processes. Mapping them to
services can be difficult. The server is essentially down during the
upgrade.
For a root filesystem, you might have to boot off the failsafe archive
or a DVD and import the filesystem in order to upgrade it.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
