Igor Brezac wrote:
> We are on Solaris 10 U3 with relatively recent recommended patches applied.
> zfs destroy of a filesystem takes a very long time; 20GB usage and about 5
> million objects takes about 10 minutes to destroy. zfs pool is a 2 drive
> stripe, nothing too fancy. We do not have
We are on Solaris 10 U3 with relatively recent recommended patches applied.
zfs destroy of a filesystem takes a very long time; 20GB usage and about 5
million objects takes about 10 minutes to destroy. zfs pool is a 2 drive
stripe, nothing too fancy. We do not have any snapshots.
Any ideas?
> I tried to copy a 8GB Xen domU disk image from a zvol device
> to an image file on an ufs filesystem, and was surprised that
> reading from the zvol character device doesn't detect "EOF".
I've filed bug 6596419...
This message posted from opensolaris.org
_
> I tried to copy a 8GB Xen domU disk image from a zvol device
> to an image file on an ufs filesystem, and was surprised that
> reading from the zvol character device doesn't detect "EOF".
>
> On snv_66 (sparc) and snv_73 (x86) I can reproduce it, like this:
>
> # zfs create -V 1440k tank/floppy
Mark wrote:
> Hey,
>
> I will submit it. However does Opensolaris have a seperate HCL? or do i just
> use the solaris one?
Last time I tried to submit anything, they didn't even accepted
sxcr release numbers, only proper Solaris releases numbers.
--
Kaiser Jasse -- Authorized Stealth Oracle
I tried to copy a 8GB Xen domU disk image from a zvol device
to an image file on an ufs filesystem, and was surprised that
reading from the zvol character device doesn't detect "EOF".
On snv_66 (sparc) and snv_73 (x86) I can reproduce it, like this:
# zfs create -V 1440k tank/floppy-img
# dd if=
Hello Roch,
Wednesday, August 22, 2007, 10:13:10 AM, you wrote:
RP> £ukasz K writes:
>> > Is ZFS efficient at handling huge populations of tiny-to-small files -
>> > for example, 20 million TIFF images in a collection, each between 5
>> > and 500k in size?
>> >
>> > I am asking because I co
Hello Ralf,
Wednesday, August 22, 2007, 8:55:35 AM, you wrote:
RR> instead, or, most important for the typical data center, the *operator*
RR> is not able to replace a disk like he's used to: pulling the old disc
RR> out, putting the new disc in, resync starting, finished. You'll always
RR> have
