I had a pool, p, with a filesystem p/local, mounted at /local. In that are
several workspace filesystems, including "/local/ws/install-nv".
I used "mv" from /local/ws to change install-nv to nv-install.
it worked. nothing seemed wrong, except the output of "zfs list".
Then I remembered there
My system (a laptop with ZFS root and boot, SNV 64A) on which I was trying
Opensolaris now has the zpool-related kernel panic reboot loop.
Booting into failsafe mode or another solaris installation and attempting:
'zpool import -F rootpool' results in a kernel panic and reboot.
A search shows
Łukasz K wrote:
> Hello Matthew,
>
>I have problems with pool fragmentation.
> http://www.opensolaris.org/jive/thread.jspa?threadID=34810
>
> Now I want to speed up zfs send, because our pool space maps are
> huge - after sending space maps will be smaller ( from 1GB -> 50MB ).
>
> As I unde
Łukasz wrote:
>> You're right that we need to issue more i/os in
>> parallel -- see 6333409
>> "traversal code should be able to issue multiple
>> reads in parallel"
>
> When do you think it will be available ?
Perhaps by the end of the calendar year, but perhaps longer. Maybe sooner
if you wo
The argument was c1d0s0 in the first place, i.e.:
installgrub pathToStage1 pathToStage2 /dev/rdsk/c1d0s0
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs
> > Ł> I want to parallize zfs send to make it faster.
> > Ł> dmu_sendbackup could allocate buffer, that will
> be used for buffering output.
> > Ł> Few threads can traverse dataset, few threads
> would be used for async read operations.
> >
> > Ł> I think it could speed up zfs send operation
> 1
