On Aug 4, 2010, at 12:20 AM, Khyron wrote:
I notice you use the word "volume" which really isn't accurate or
appropriate here.
Yeah, it didn't seem right to me, but I wasn't sure about the
nomenclature, thanks for clarifying.
You may want to get a bit more specific and choose from the oldest
datasets THEN find the smallest of those oldest datasets and
send/receive it first. That way, the send/receive completes in less
time, and when you delete the source dataset, you've now created
more free space on the entire pool but without the risk of a single
dataset exceeding your 10 TiB of workspace.
That makes sense, I'll try send/receiving a few of those datasets and
see how it goes. I believe I can find the ones that were created
before the two new VDEVs were added, by comparing the creation time
from "zfs get creation"
ZFS' copy-on-write nature really wants no less than 20% free because
you never update data in place; a new copy is always written to disk.
Right, and my problem is that I have two VDEVs with less than 10% free
at this point -- although the other two have around 50% free each.
You might want to consider turning on compression on your new datasets
too, especially if you have free CPU cycles to spare. I don't know
how
compressible your data is, but if it's fairly compressible, say lots
of text,
then you might get some added benefit when you copy the old data into
the new datasets. Saving more space, then deleting the source
dataset,
should help your pool have more free space, and thus influence your
writes for better I/O balancing when you do the next (and the next)
dataset
copies.
Unfortunately the data taking most of the space it already compressed,
so while I would gain some space from many text files that I also
have, those are not the majority of my content, and the effort would
probably not justify the small gain.
Thanks
Eduardo Bragatto
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
