gmane.os.solaris.opensolaris.zfs
http://blog.gmane.org/gmane.os.solaris.opensolaris.zfs
hourly11901-01-01T00:00+00:00Gmanehttp://gmane.org/img/gmane-25t.png
http://gmane.org
MPxIO n00b question
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49231
<pre>I'm currently trying to get a SuperMicro JBOD with dual SAS expander
chips running in MPxIO, but I'm a total amateur to this and would like
to ask about how to detect whether MPxIO is working (or not).
My SAS topology is:
*) One LSI SAS2008-equipped HBA (running the latest IT firmware from
LSI) with two external ports.
*) Two SAS cables running from the HBA to the SuperMicro JBOD, where
they enter the JBOD's rear backplane (which is equipped with two
LSI SAS expander chips).
*) From the rear backplane, via two internal SAS cables to the front
backplane (also with two SAS expanders on it)
*) The JBOD is populated with 45 2TB Toshiba SAS 7200rpm drives
The machine also has a PERC H700 for the boot media, configured into a
hardware RAID-1 (on which rpool resides).
Here is the relevant part from cfgadm -al for the MPxIO bits:
c5 scsi-sas connected configured
unknown
c5::dsk/c5t50000393D8CB4452d0 disk connected configured
unknown
c5::dsk/c5t50000393E8C90CF2d0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF2A6d0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF2AAd0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF2BEd0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF2C6d0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF2E2d0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF2F2d0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF5C6d0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF28Ad0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF32Ed0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF35Ad0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF35Ed0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF36Ad0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF36Ed0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF52Ed0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF53Ad0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF53Ed0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF312d0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF316d0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF506d0 disk connected configured
unknown
c5::dsk/c5t50000393E8CAF546d0 disk connected configured
unknown
c5::dsk/c5t50000393F8C84F5Ed0 disk connected configured
unknown
c5::dsk/c5t50000393F8C84FBAd0 disk connected configured
unknown
c5::dsk/c5t50000393F8C851EEd0 disk connected configured
unknown
c5::dsk/c5t50000393F8C852A6d0 disk connected configured
unknown
c5::dsk/c5t50000393F8C852C2d0 disk connected configured
unknown
c5::dsk/c5t50000393F8C852CAd0 disk connected configured
unknown
c5::dsk/c5t50000393F8C852EAd0 disk connected configured
unknown
c5::dsk/c5t50000393F8C854BAd0 disk connected configured
unknown
c5::dsk/c5t50000393F8C854E2d0 disk connected configured
unknown
c5::dsk/c5t50000393F8C855AAd0 disk connected configured
unknown
c5::dsk/c5t50000393F8C8509Ad0 disk connected configured
unknown
c5::dsk/c5t50000393F8C8520Ad0 disk connected configured
unknown
c5::dsk/c5t50000393F8C8528Ad0 disk connected configured
unknown
c5::dsk/c5t50000393F8C8530Ed0 disk connected configured
unknown
c5::dsk/c5t50000393F8C8531Ed0 disk connected configured
unknown
c5::dsk/c5t50000393F8C8557Ed0 disk connected configured
unknown
c5::dsk/c5t50000393F8C8558Ed0 disk connected configured
unknown
c5::dsk/c5t50000393F8C8560Ad0 disk connected configured
unknown
c5::dsk/c5t50000393F8C85106d0 disk connected configured
unknown
c5::dsk/c5t50000393F8C85222d0 disk connected configured
unknown
c5::dsk/c5t50000393F8C85246d0 disk connected configured
unknown
c5::dsk/c5t50000393F8C85366d0 disk connected configured
unknown
c5::dsk/c5t50000393F8C85636d0 disk connected configured
unknown
c5::es/ses0 ESI connected configured
unknown
c5::es/ses1 ESI connected configured
unknown
c5::smp/expd0 smp connected configured
unknown
c5::smp/expd1 smp connected configured
unknown
c6 scsi-sas connected configured
unknown
c6::dsk/c6t50000393D8CB4453d0 disk connected configured
unknown
c6::dsk/c6t50000393E8C90CF3d0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF2A7d0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF2ABd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF2BFd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF2C7d0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF2E3d0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF2F3d0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF5C7d0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF28Bd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF32Fd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF35Bd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF35Fd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF36Bd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF36Fd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF52Fd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF53Bd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF53Fd0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF313d0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF317d0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF507d0 disk connected configured
unknown
c6::dsk/c6t50000393E8CAF547d0 disk connected configured
unknown
c6::dsk/c6t50000393F8C84F5Fd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C84FBBd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C851EFd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C852A7d0 disk connected configured
unknown
c6::dsk/c6t50000393F8C852C3d0 disk connected configured
unknown
c6::dsk/c6t50000393F8C852CBd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C852EBd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C854BBd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C854E3d0 disk connected configured
unknown
c6::dsk/c6t50000393F8C855ABd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C8509Bd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C8520Bd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C8528Bd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C8530Fd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C8531Fd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C8557Fd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C8558Fd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C8560Bd0 disk connected configured
unknown
c6::dsk/c6t50000393F8C85107d0 disk connected configured
unknown
c6::dsk/c6t50000393F8C85223d0 disk connected configured
unknown
c6::dsk/c6t50000393F8C85247d0 disk connected configured
unknown
c6::dsk/c6t50000393F8C85367d0 disk connected configured
unknown
c6::dsk/c6t50000393F8C85637d0 disk connected configured
unknown
c6::es/ses2 ESI connected configured
unknown
c6::es/ses3 ESI connected configured
unknown
c6::smp/expd2 smp connected configured
unknown
c6::smp/expd3 smp connected configured
unknown
I can see all drives in format(1M), but "mpathadm list lu" doesn't show
anything, even after I did "stmsboot -e" (and rebooted). Can anybody
please help me find out whether MPxIO is properly enabled and how I can
start using it? My understanding is that MPxIO should mask each drive
under some common name (e.g. c5t20d0) and underneath handle all of the
multipathing internally, but maybe I'm wrong and it behaves completely
differently. I'd like to create a 5x 9-drive raidz's on the JBOD, but
I'm not sure how to do it now that I can see each drive twice...
All help greatly appreciated!
Cheers,
--
Saso
</pre>Sašo Kiselkov2012-05-25T17:07:15Anybody running S10 or 11 on AMD bulldozer 8 core?
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49230
<pre>I have a chance to pick up a system at a reasonable price built with an AMD
FX8120 8 core 3.1 GHz on a Gigabyte motherboard. Is anybody runing with this
combo? Looking for info from an actual user. Thanks.
</pre>Nomen Nescio2012-05-25T16:01:30dataset is busy when doing snapshot
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49212
<pre>What causes these messages?
cannot create snapshot 'zones/rani/ROOT/zbe-2< at >migration': dataset is busy
There are zones living in zones pool, but none of the zones are running or mounted.
root< at >:~# zfs get -r mounted,zoned,mountpoint zones/rani
NAME PROPERTY VALUE SOURCE
zones/rani mounted yes -
zones/rani zoned off default
zones/rani mountpoint /zones/rani default
zones/rani/ROOT mounted no -
zones/rani/ROOT zoned on local
zones/rani/ROOT mountpoint legacy local
zones/rani/ROOT< at >original mounted - -
zones/rani/ROOT< at >original zoned - -
zones/rani/ROOT< at >original mountpoint - -
zones/rani/ROOT/zbe-2 mounted no -
zones/rani/ROOT/zbe-2 zoned on local
zones/rani/ROOT/zbe-2 mountpoint legacy inherited from zones/rani/ROOT
root< at >:~#
This is on a very old OS now snv_134b… I am working to upgrade them soon!
</pre>Anil Jangity2012-05-20T04:18:06Zpool import FAULTED
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49207
<pre>Dears,
I need help to get my pool online again.
root< at >node1 # zdb -l /dev/dsk/c2t1d15****
--------------------------------------------****
LABEL 0****
--------------------------------------------****
failed to unpack label 0****
--------------------------------------------****
LABEL 1****
--------------------------------------------****
failed to unpack label 1****
--------------------------------------------****
LABEL 2****
--------------------------------------------****
failed to unpack label 2****
--------------------------------------------****
LABEL 3****
--------------------------------------------****
failed to unpack label 3****
root< at >node1 # zdb -l /dev/dsk/c4t2d19****
--------------------------------------------****
LABEL 0****
--------------------------------------------****
failed to unpack label 0****
--------------------------------------------****
LABEL 1****
--------------------------------------------****
failed to unpack label 1****
--------------------------------------------****
LABEL 2****
--------------------------------------------****
failed to unpack label 2****
--------------------------------------------****
LABEL 3****
--------------------------------------------****
failed to unpack label 3
Output of Node1 import:****
root< at >node1 # zpool import****
pool: b2d_cbs****
id: 11888884672293294835****
state: FAULTED****
status: One or more devices contains corrupted data.****
action: The pool cannot be imported due to damaged devices or data.****
see: http://www.sun.com/msg/ZFS-8000-4J****
config:****
** **
b2d_cbs FAULTED insufficient replicas****
c2t1d16 ONLINE****
c2t1d17 ONLINE****
c2t1d15 FAULTED corrupted data****
c2t1d18 ONLINE****
c4t2d19 FAULTED corrupted data****
c2t1d20 ONLINE****
c2t1d12 ONLINE****
c2t1d4 ONLINE****
c2t1d5 ONLINE****
c2t1d6 ONLINE****
c2t1d7 ONLINE****
c2t1d8 ONLINE****
c2t1d9 ONLINE****
c2t1d10 ONLINE****
c2t1d11 ONLINE
_______________________________________________
zfs-discuss mailing list
zfs-discuss< at >opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
</pre>Mohamed Magdy2012-05-18T02:28:43How does resilver/scrub work?
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49201
<pre>Hello all,
While waiting for that resilver to complete last week,
I caught myself wondering how the resilvers (are supposed
to) work in ZFS?
Based on what I see in practice and read in this list
and some blogs, I've built a picture and would be grateful
if some experts actually familiar with code and architecture
would say how far off I guessed from the truth ;)
Ultimately I wonder if there are possible optimizations
to make the scrub process more resembling a sequential
drive-cloning (bandwidth/throughput-bound), than an
IOPS-bound random seek thrashing for hours that we
often see now, at least on (over?)saturated pools.
This may possibly improve zfs send speeds as well.
First of all, I state (and ask to confirm): I think
resilvers are a subset of scrubs, in that:
1) resilvers are limited to a particular top-level VDEV
(and its number is a component of each block's DVA address)
and
2) when scrub finds a block mismatching its known checksum,
scrub reallocates the whole block anew using the recovered
known-valid data - in essence it is a newly written block
with a new path in BP tree and so on; a resilver expects
to have a disk full of known-missing pieces of blocks,
and reconstructed pieces are written on the resilvering
disk "in-place" at an address dictated by the known DVA -
this allows to not rewrite the other disks and BP tree
as COW would otherwise require.
Other than these points, resilvers and scrubs should
work the same, perhaps with nuances like separate tunables
for throttling and such - but generic algorithms should
be nearly identical.
Q1: Is this assessment true?
So I'll call them both a "scrub" below - it's shorter :)
Now, as everybody knows, at least by word-of-mouth on
this list, the scrub tends to be slow on pools with a rich
life (many updates and deletions, causing fragmentation,
with "old" and "young" blocks intermixed on disk), more
so if the pools are quite full (over about 80% for some
reporters). This slowness (on non-SSD disks with non-zero
seek latency) is attributed to several reasons I've seen
stated and/or thought up while pondering. The reasons may
include statements like:
1) "Scrub goes on in TXG order".
If it is indeed so - the system must find older blocks,
then newer ones, and so on. IF the block-pointer tree
starting from uberblock is the only reference to the
entirety of the on-disk blocks (unlike say DDT) then
this tree would have to be read into memory and sorted
by TXG age and then processed.
From my system's failures I know that this tree would
take about 30Gb on my home-NAS box with 8Gb RAM, and
the kernel crashes the machine by depleting RAM and
not going into swap after certain operations (i.e.
large deletes on datasets with enabled deduplication).
That was discussed last year by me, and recently by
other posters.
Since the scrub does not do that and does not even
press on RAM in a fatal manner, I think this "reason"
is wrong. I also fail to see why one would do that
processing ordering in the first place - on a fairly
fragmented system even the blocks from "newer" TXGs
do not necessarily follow those from the "previous"
ones.
What this rumour could reflect, however, is that a scrub
(or more importantly, a resilver) are indeed limited by
the "interesting" range of TXGs, such as picking only
those blocks which were written between the last TXG that
a lost-and-reconnected disk knew of (known to the system
via that disk's stale uberblock), and the current TXG
at the moment of its reconnection. Newer writes would
probably land onto all disks anyway, so a resilver has
only to find and fix those missing TXG numbers.
In my problematic system however I only saw full resilvers
even after they restarted numerously... This may actually
support the idea that scrubs are NOT txg-ordered, otherwise
a regularly updated tabkeeping attribute on the disk (in
uberblock?) would note that some TXGs are known to fully
exist on the resilvering drive - and this is not happening.
2) "Scrub walks the block-pointer tree".
That seems like a viable reason for lots of random reads
(hitting the IOPS barrier). It does not directly explain
the reports I think I've seen about L2ARC improving scrub
speeds and system responsiveness - although extra caching
takes the repetitive load off the HDDs and leaves them
some more timeslices to participate in scrubbing (and
*that* should incur reads from disks, not caches).
On an active system, block pointer entries are relatively
short-lived, with whole branches of a tree being updated
and written in a new location upon every file update.
This image is bound to look like good cheese after a while
even if the writes were initially coalesced into few IOs.
3) "If there are N top-level VDEVs in a pool, then only
the one with the resilvering disk would be hit for
performance" - not quite true, because pieces of the
BPtree are spread across all VDEVs. The one resilvering
would get the most bulk traffic, when DVAs residing on
it are found and userdata blocks get transferred, but
random read seeks caused by the resilvering process
should happen all over the pool.
Q2: Am I correct with the interpretation of statements 1-3?
IDEA1
One optimization that could take place here would be to
store some of the BPs' ditto copies in compact locations
on disk (not all over it evenly), albeit maybe hurting
the write performance. This way a resilver run, or even
a scrub or zfs send, might be like a vdev-prefetch - a
scooping read of several megabytes worth of blockpointers
(this would especially help if the whole tree would fit
in RAM/L2ARC/swap), then sorting out the tree or its major
branches. The benefit would be little mechanical seeking
for lots of BP data. This might possibly require us to
invalidate the freed BP slots somehow as well :\
In case of scrubs, where we would have to read in all of
the allocated blocks from the media to test it, this would
let us schedule a sequential read of the drives userdata
while making sense of the sectors we find (as particular
zfs blocks).
In case of resilvering - this would let us find DVAs of
blocks in the interesting TLVDEV and in the TXG range and
also schedule huge sequential reads instead of random
seeking.
In case of zfs send, this would help us pick out the
TXG-limited ranges of the blocks for a dataset, and
again schedule the sequential reads for userdata (if any).
Q3: Does the IDEA above make sense - storing BP entries
(one of the ditto blocks) in some common location on disk,
so as to minimize mechanical seeks while reading much of
the BP tree?
IDEA2
It seems possible to enable defragmentation of the BP tree
(those ditto copies that are stored together) by just
relocating the valid ones in correct order onto a free
metaslab. It seems that ZFS keeps some free space for
passive defrag purposes anyway - why not use it actively?
Live migration of blocks like this seems to be available
with scrub's repair of the mismatching blocks. However,
here some care should be taken to take into account that
the parent blockpointers would also need to be reallocated
since the childrens' checksums would change - so the whole
tree/branch of reallocations would have to be planned and
written out in sequential order onto the spare free space.
Overall, if my understanding somewhat resembles how things
really are, these ideas may help create and maintain such
layout of metadata that it can be bulk-read, which is IMHO
critical for many operations as well as to shorted recovery
windows when resilvering disks.
Q4: I wonder if similar (equivalent) solutions are already
in place and did not help much? ;)
Thanks,
//Jim
</pre>Jim Klimov2012-05-17T23:05:09zfs_arc_max values
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49184
<pre>Does anyone know what the minimum value for zfs_arc_max should be set
to? Does it depend on the amount of memory on the system, and - if so -
is there a formula, or percentage, to use to determine what the minimum
value is?
Thanks
Richard Paynter
Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
_______________________________________________
zfs-discuss mailing list
zfs-discuss< at >opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
</pre>Paynter, Richard2012-05-16T19:35:25Hard Drive Choice Question
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49174
<pre> I have a small server at home (HP Proliant Micro N36) that I use
for file, DNS, DHCP, etc. services. I currently have a zpool of four
mirrored 1 TB Seagate ES2 SATA drives. Well, it was a zpool of four
until last night when one of the drives died. ZFS did it's job and all
the data is still OK.
The drive is still under warranty and is going back to Seagate,
but it raised an issue. I want to pick up a spare drive or two so that
I don't have to wait for shipping delays when a drive fails. I was
just going to pick up another 1 TB ES2 or two, but I find that those
drives are no longer available (I bought mine in 2009, warranty is up
in 2014).
What do people like today for 7x24 operation SATA drives? I am
willing to consider 2TB, but don't really need the extra capacity (but
if that is all the market offers, I don't have to use the other half
:-) I found a Seagate Constellation ES 2 TB for about $350 (which is
more than I really want to spend, I got the ES2 1TB drives for about
$130 when I bought them). I have been sticking with Seagate as I am
comfortable with them, but am willing to look at others. The only
thing I insist on is that the drive be rated for 7x24 operation.
Thanks, in advance for all of your informed opinions.
P.S. I am sending this to TWO lists, please do NOT respond to the list
you are NOT subscribed to :-)
</pre>Paul Kraus2012-05-16T14:53:36ZFS and zpool for NetApp FC LUNs
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49170
<pre>Hi All,
I have FC LUNs from NetApp FAS 3240 mapped to two SPARC T4-2 clustered
nodes running Veritas Cluster Server software. For now, the
configuration on NetApp is as follows:
/vol/EBUSApp/EBUSApp 100G
online MBSUN04 : 0 MBSUN05 : 0
/vol/EBUSBinry/EBUSBinry 200G
online MBSUN04 : 1 MBSUN05 : 1
/vol/EBUSCtrlog/EBUSCtrlog 5G
online MBSUN04 : 2 MBSUN05 : 2
/vol/EBUSDB/EBUSDB
300.0G online MBSUN04 : 3 MBSUN05 : 3
/vol/EBUSIO_FENC1/EBUSIO_FENC1 5G online
MBSUN04 : 4 MBSUN05 : 4
/vol/EBUSIO_FENC2/EBUSIO_FENC2 5G online
MBSUN04 : 5 MBSUN05 : 5
/vol/EBUSIO_FENC3/EBUSIO_FENC3 5G online
MBSUN04 : 6 MBSUN05 : 6
/vol/EBUSRDlog/EBUSRDlog 5G
online MBSUN04 : 7 MBSUN05 : 7
I will be mapping the above volumes on hosts and creating zpool andzfs
file system. More volumes will be created in the future.
Is it certified by Symantec to use ZFS and Zpool for SnapMirror?
At the moment, Veritas Cluster Server software is installed on 2
servers at the primary site and there is no cluster software on the DR
site. NetApp FAS 3240 provides FC LUNs to the 2 clustered nodes at the
primary site and the same filer also provides different LUNs to the
server at the DR site. The two clustered nodes at primary site are
“mbsun4” and “mbsun5”. The server at DR site is “mbsun6.
To list the steps that were carried out:
On mbsun4:
We create a ZFS pool from the LUN carved out of NetApp filer:
# zpool create -f orapool c0t60A98000646E2F6F67346A79642D6570d0
We then create the file sytem.
# zfs create orapool/vol01
We bring the mount under Veritas Cluster Server control:
# zfs set mountpoint=legacy orapool/vol01
# zpool export orapool
We then execute the following commands on the other cluster node:
On mbsun5:
# zpool import orapool
# zfs create orapool/vol01
# zfs set mountpoint=legacy orapool/vol01
Once configured under Veritas Cluster Server, the ZFS mount and Zpool
will failover among clustered nodes.
At the DR site (there is no cluster software), the server is called
“mbsun6”, we execute the following commands to create a different
Zpool and ZFS file system:
# zpool create -f orapool c0t60A98000646E2F6F67346B3145653874d0
# zfs create orapool/vol01
# zfs set mountpoint=/vol01 orapool/vol01
NetApp Snapmirror will be used to replicate the volumes from the
primary to DR site and we want know if we can use Zpool and ZFS
instead of the old UFS file system.
My question is:
Is it a good idea to use Zpool for these devices and then create ZFS
file system or just use ZFS file system? Will replication through
NetApp Snapmirror work when we use Zpools and ZFS?
Is it certified by Symantec to use ZFS and Zpool for SnapMirror?
If Zpools can be used, is it a good idea to create a single ZFS zpool
and add all the devices or create multiple ZFS zpools and map each
device to the individual zpool?
Regards,
Bruce
</pre>Bruce McGill2012-05-16T09:20:55Dell PERC H200: drive failed to power up
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49166
<pre>Hi,
I'm getting weird errors while trying to install openindiana 151a on a
Dell R715 with a PERC H200 (based on an LSI SAS 2008). Any time the OS
tries to access the drives (for whatever reason), I get this dumped into
syslog:
genunix: WARNING: Device
/pci< at >0,0/pci1002,5a18< at >4/pci10b58424< at >0/pci10b5,8624< at >0/pci1028,1f1e< at >0/iport< at >40/disk< at >w50000c0f01004ebe,0
failed to power up
genunix: WARNING: Device
/pci< at >0,0/pci1002,5a18< at >4/pci10b58424< at >0/pci10b5,8624< at >0/pci1028,1f1e< at >0/iport< at >80/disk< at >w50000c0f01064e9e,0
failed to power up
(these are two WD 300GB 10k SAS drives)
When this log message shows up, I can see each drive light up the drive
LED briefly and then it turns off, so apparently the OS tried to
initialize the drives, but somehow failed and gave up.
Consequently, when I try and access them in format(1), they show up as
an unknown type and installing openindiana on them fails while the
installer is trying to do fdisk.
Has anybody got any idea what I can do to the controller/drives/whatever
to fix the "failed to power up" problem? One would think that a LSI SAS
2008 chip would be problem free under Solaris (the server even lists
Oracle Solaris as an officially supported OS), but alas, I have yet to
succeed.
Cheers,
--
Saso
</pre>Sašo Kiselkov2012-05-16T07:14:18Migration of a Thumper to bigger HDDs
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49162
<pre>Hello all, I'd like some practical advice on migration of a
Sun Fire X4500 (Thumper) from aging data disks to a set of
newer disks. Some questions below are my own, others are
passed from the customer and I may consider not all of them
sane - but must ask anyway ;)
1) They hope to use 3Tb disks, and hotplugged an Ultrastar 3Tb
for testing. However, the system only sees it as a 802Gb
device, via Solaris format/fdisk as well as via parted [1].
Is that a limitation of the Marvell controller, disk,
the current OS (snv_117)? Would it be cleared by a reboot
and proper disk detection on POST (I'll test tonight) or
these big disks won't work in X4500, period?
[1]
http://code.google.com/p/solaris-parted/downloads/detail?name=solaris-parted-0.2.tar.gz&can=2&q=
Gotta run now, will ask more in the evening :)
Thanks for now,
//Jim
</pre>Jim Klimov2012-05-15T09:41:50Unexpected error adding a cache device to existingpool
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49159
<pre>On a Solaris 11 system I have a pool that was originally built with a
log a cache device on a single SSD. The SSD died and I realised I
should have a mirror log, so I've just tried to replace the log a cache
with a pair of SSDs.
Adding the log was OK:
zpool add -f export log mirror c10t3d0s0 c10t4d0s0
But adding the cache fails:
zpool add -f export cache c10t3d0s1 c10t4d0s1
invalid vdev specification
the following errors must be manually repaired:
/dev/dsk/c10t3d0s2 is part of active ZFS pool export. Please see zpool(1M).
/dev/dsk/c10t3d0s1 overlaps with /dev/dsk/c10t3d0s2
Now that looks impossible to repair, s2 can't be removed. The SSD
partition table is:
Total disk cylinders available: 19932 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks
0 unassigned wm 0 - 2674 16.00GB (2675/0/0) 33555200
1 unassigned wm 2675 - 19931 103.22GB (17257/0/0) 216471808
2 backup wu 0 - 19931 119.22GB (19932/0/0) 250027008
Is there a solution?
</pre>Ian Collins2012-05-14T09:02:48Resilver restarting several times
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49144
<pre>Hello all,
SHORT VERSION:
What conditions can cause the reset of the resilvering
process? My lost-and-found disk can't get back into the
pool because of resilvers restarting...
LONG VERSION:
I maintain a number of older systems, and among them
a Sun Thumper (X4500) running OpenSolaris SXCE with
nowadays-smallish 250Gb disks and a ZPOOL v14 (with the
OS supporting ZPOOLv16). This year it has "lost contact"
with two different drives, however a poweroff followed
by poweron restored the contact.
On the first time a couple of months ago the system
successfully used the hotspare disk with no issues
worth mentioning or remembering.
This week however the hotspare took days to get used
and ultimately didn't, with pool CKSUM errors growing
into millions on the lost disk, and dmesg clobbered with
messages about the lost drive. There was even no message
about resilvering in "zpool status", other than that the
hotspare is "IN USE".
After a reboot the disk was re-found and the resilver
went humming along, with the hotspare still marked as
used. The error count is non-zero but stable overnight,
and no data loss was reported:
pool: pond
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scrub: resilver in progress for 0h49m, 9.52% done, 7h46m to go
config:
NAME STATE READ WRITE CKSUM
pond ONLINE 0 0 0
...
raidz1 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
spare ONLINE 0 0 46
c1t2d0 ONLINE 0 0 0 17.3G resilvered
c5t6d0 ONLINE 0 0 0
c4t3d0 ONLINE 0 0 0
c6t5d0 ONLINE 0 0 0
c7t6d0 ONLINE 0 0 0
...
spares
c5t6d0 INUSE currently in use
errors: No known data errors
The problem I come here with is that the resilver does not
complete. It got reset after about 40, 84, 80Gb of resilvered
progress and restarts from scratch. I hoped that it would at
least progress further each time, but that seems to be not
true as of the last two restarts.
The pool is indeed active, used by zfs-auto-snapshots in
particular (I disabled them for now while asking - they do
also perform very slowly, with some "zfs destroy" invokations
overlaying each other and failing due to missing targets).
There are no correlating errors in dmesg that would point
me at a problem, and the CKSUM count stays the same.
So far I guess that the stale disk may be found referencing
some transactions that are gone from the live pool (i.e. via
deletion of automatic snapshots), but I didn't think this
should cause a restart of the whole resilvering process?..
The system must be quite fragmented I guess, because the
resilver of a 250Gb disk is promised to complete in 10 hours
(after each report - even if 80Gb are behind).
"zpool iostat 60" shows low figures, about 1Mb/s writes and
about 5Mb/s reads; "iostat -xnz 1" also shows low utilizations
on drives in general (about 5-10%busy, 500-900Kb/s reads), but
with a bigger peak on the recovering raidz's drives and the
hotspare disk. But even these numbers usually seem within the
bounds of IOPS or bandwidth bottlenecks:
# iostat -xzn c0t1d0 c1t2d0 c5t6d0 c4t3d0 c6t5d0 c7t6d0 1
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
107.5 21.1 5200.2 93.1 1.3 0.9 10.0 6.9 22 37 c0t1d0
107.7 21.2 5200.7 93.2 1.2 0.9 9.6 7.0 22 37 c4t3d0
107.2 21.1 5199.6 93.2 1.3 0.9 10.0 7.1 22 38 c6t5d0
107.6 21.1 5199.2 93.2 1.2 0.9 9.5 7.3 21 37 c7t6d0
1.5 200.0 71.3 4574.1 0.5 0.4 2.7 1.9 10 16 c1t2d0
106.9 21.2 5124.4 93.1 1.1 0.9 8.8 7.1 20 35 c5t6d0
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
177.9 0.0 4251.1 0.0 1.2 0.4 6.9 2.0 28 35 c0t1d0
156.8 0.0 4074.2 0.0 1.1 0.4 6.8 2.3 25 35 c4t3d0
156.8 0.0 4048.1 0.0 0.4 1.1 2.6 6.8 12 33 c6t5d0
156.8 0.0 4188.3 0.0 1.2 0.4 7.6 2.6 30 41 c7t6d0
0.0 343.8 0.0 2927.3 0.1 0.1 0.4 0.2 5 6 c1t2d0
167.9 0.0 4017.4 0.0 1.3 0.4 7.7 2.3 29 37 c5t6d0
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
113.0 114.0 2588.9 134.5 1.7 0.3 7.4 1.5 29 33 c0t1d0
79.0 122.0 2777.0 144.0 1.6 0.4 7.9 1.8 33 37 c4t3d0
98.0 122.0 2775.0 144.5 0.6 1.1 2.8 4.9 17 35 c6t5d0
125.0 125.0 2946.0 144.0 1.5 0.3 6.0 1.3 27 33 c7t6d0
0.0 395.1 0.0 2363.4 0.3 0.1 0.9 0.2 7 9 c1t2d0
131.0 114.0 3091.5 138.5 1.5 0.4 6.0 1.5 30 36 c5t6d0
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
82.0 80.0 1715.7 62.0 0.5 0.2 3.4 1.3 9 21 c0t1d0
75.0 69.0 1673.8 57.5 0.7 0.2 4.8 1.4 11 20 c4t3d0
68.0 69.0 1607.8 58.5 0.3 0.5 1.9 3.9 8 22 c6t5d0
71.0 74.0 1539.8 57.0 0.5 0.2 3.1 1.2 8 17 c7t6d0
0.0 205.0 0.0 1079.3 0.2 0.0 0.9 0.2 4 4 c1t2d0
72.0 77.0 1679.8 60.0 0.6 0.2 3.9 1.3 12 19 c5t6d0
What conditions can cause the reset of the resilvering
process? And how can it be sped up to complete other than
disabling zfs auto-snapshots? There are no other heavy users
of the system, though several VMs and webapp servers run off
the pool's data, and can not be put down...
The knobs I know from OI did not work here:
# echo zfs_resilver_delay/W0t0 | mdb -kw
mdb: failed to dereference symbol: unknown symbol name
# echo zfs_resilver_min_time_ms/W0t20000 | mdb -kw
mdb: failed to dereference symbol: unknown symbol name
Thanks for any ideas,
//Jim Klimov
</pre>Jim Klimov2012-05-11T10:22:58Strange hang during snapshot receive
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49140
<pre>I have an application I have been using to manage data replication for a
number of years. Recently we started using a new machine as a staging
server (not that new, an x4540) running Solaris 11 with a single pool
built from 7x6 drive raidz. No dedup and no reported errors.
On that box and nowhere else is see empty snapshots taking 17 or 18
seconds to write. Everywhere else they return in under a second.
Using truss and the last published source code, it looks like the pause
is between a printf and the call to zfs_ioctl and there aren't any
other functions calls between them:
100.5124 0.0004 open("/dev/zfs", O_RDWR|O_EXCL) = 10
100.7582 0.0001 read(7, "\0\0\0\0\0\0\0\0ACCBBAF5".., 312) = 312
100.7586 0.0000 read(7, 0x080464F8, 0) = 0
100.7591 0.0000 time() = 1336628656
100.7653 0.0035 ioctl(8, ZFS_IOC_OBJSET_STATS, 0x08040CF0) = 0
100.7699 0.0022 ioctl(8, ZFS_IOC_OBJSET_STATS, 0x08040900) = 0
100.7740 0.0016 ioctl(8, ZFS_IOC_OBJSET_STATS, 0x08040580) = 0
100.7787 0.0026 ioctl(8, ZFS_IOC_OBJSET_STATS, 0x080405B0) = 0
100.7794 0.0001 write(1, " r e c e i v i n g i n".., 75) = 75
118.3551 0.6927 ioctl(8, ZFS_IOC_RECV, 0x08042570) = 0
118.3596 0.0010 ioctl(8, ZFS_IOC_OBJSET_STATS, 0x08040900) = 0
118.3598 0.0000 time() = 1336628673
118.3600 0.0000 write(1, " r e c e i v e d 3 1 2".., 45) = 45
zpool iostat (1 second interval) for the period is:
tank 12.5T 6.58T 175 0 271K 0
tank 12.5T 6.58T 176 0 299K 0
tank 12.5T 6.58T 189 0 259K 0
tank 12.5T 6.58T 156 0 231K 0
tank 12.5T 6.58T 170 0 243K 0
tank 12.5T 6.58T 252 0 295K 0
tank 12.5T 6.58T 179 0 200K 0
tank 12.5T 6.58T 214 0 258K 0
tank 12.5T 6.58T 165 0 210K 0
tank 12.5T 6.58T 154 0 178K 0
tank 12.5T 6.58T 186 0 221K 0
tank 12.5T 6.58T 184 0 215K 0
tank 12.5T 6.58T 218 0 248K 0
tank 12.5T 6.58T 175 0 228K 0
tank 12.5T 6.58T 146 0 194K 0
tank 12.5T 6.58T 99 258 209K 1.50M
tank 12.5T 6.58T 196 296 294K 1.31M
tank 12.5T 6.58T 188 130 229K 776K
Can anyone offer any insight or further debugging tips?
Thanks.
</pre>Ian Collins2012-05-10T10:37:06Broken ZFS filesystem
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49133
<pre>I have an interesting issue with one single ZFS filesystem in a pool.
All the other filesystems are fine, and can be mounted, snapshoted,
destroyed, etc. But this one filesystem, if I try to do any operation
on it (zfs mount, zfs snapshot, zfs destroy, zfs set <anything>), it
spins the system until all RAM is used up (wired), and then hangs the
box. The zfs process sits in tx -> tx_sync_done_cv state until the
box locks up. CTRL+T of the process only ever shows this:
load: 0.46 cmd: zfs 3115 [tx->tx_sync_done_cv)] 36.63r 0.00u 0.00s 0% 2440k
Anyone come across anything similar? And found a way to fix it, or to
destroy the filesystem? Any suggestions on how to go about debugging
this? Any magical zdb commands to use?
The filesystem only has 5 MB of data in it (log files), compressed via
LZJB for a compressratio of ~6x. There are no snapshots for this
filesystem.
Dedupe is enabled on the pool and all filesystems.
System is running 64-bit FreeBSD 9.0:
FreeBSD alphadrive.sd73.bc.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0
r229803: Sun Jan 8 00:43:00 PST 2012
root< at >alphadrive.sd73.bc.ca:/usr/obj/usr/src/sys/ZFSHOST90 amd64
Hardware is fairly generic:
- SuperMicro H8DGi-F motherboard
- AMD Opteron 6128 CPU (8 cores)
- 24 GB of DDR3 RAM
- 3x SuperMicro AOC-USAS-L8i SATA controllers
- 24x harddrives ranging from 500 GB to 2.0 TB (6 of each kind in
raidz2 vdevs)
- 64 GB SSD partitioned for OS, swap, with 32 GB for L2ARC
Filesystem properties:
# zfs get all storage/logs/rsync
NAME PROPERTY VALUE SOURCE
storage/logs/rsync type filesystem -
storage/logs/rsync creation Tue May 10 9:55 2011 -
storage/logs/rsync used 5.48M -
storage/logs/rsync available 4.61T -
storage/logs/rsync referenced 5.48M -
storage/logs/rsync compressratio 5.93x -
storage/logs/rsync mounted no -
storage/logs/rsync quota none default
storage/logs/rsync reservation none default
storage/logs/rsync recordsize 128K default
storage/logs/rsync mountpoint /var/log/rsync local
storage/logs/rsync sharenfs off default
storage/logs/rsync checksum sha256
inherited from storage
storage/logs/rsync compression lzjb
inherited from storage
storage/logs/rsync atime off
inherited from storage
storage/logs/rsync devices on default
storage/logs/rsync exec on default
storage/logs/rsync setuid on default
storage/logs/rsync readonly off default
storage/logs/rsync jailed off default
storage/logs/rsync snapdir visible
inherited from storage
storage/logs/rsync aclmode discard default
storage/logs/rsync aclinherit restricted default
storage/logs/rsync canmount on default
storage/logs/rsync xattr on default
storage/logs/rsync copies 1 default
storage/logs/rsync version 5 -
storage/logs/rsync utf8only off -
storage/logs/rsync normalization none -
storage/logs/rsync casesensitivity sensitive -
storage/logs/rsync vscan off default
storage/logs/rsync nbmand off default
storage/logs/rsync sharesmb off default
storage/logs/rsync refquota none default
storage/logs/rsync refreservation none default
storage/logs/rsync primarycache all
inherited from storage
storage/logs/rsync secondarycache metadata
inherited from storage
storage/logs/rsync usedbysnapshots 0 -
storage/logs/rsync usedbydataset 5.48M -
storage/logs/rsync usedbychildren 0 -
storage/logs/rsync usedbyrefreservation 0 -
storage/logs/rsync logbias latency default
storage/logs/rsync dedup sha256
inherited from storage
storage/logs/rsync mlslabel -
storage/logs/rsync sync standard default
storage/logs/rsync refcompressratio 5.93x
</pre>Freddie Cash2012-05-08T17:24:48slow zfs send
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49121
<pre>Hi,
I'm showing slow zfs send on pool v29. About 25MB/sec
bash-3.2# zpool status vdipool
pool: vdipool
state: ONLINE
scan: scrub repaired 86.5K in 7h15m with 0 errors on Mon Feb 6
01:36:23 2012
config:
NAME STATE READ WRITE CKSUM
vdipool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c0t5000C500103F2057d0 ONLINE 0 0 0
(SEAGATE-ST31000640SS-0003-931.51GB) Promise Jbod
c0t5000C5000440AA0Bd0 ONLINE 0 0 0
(SEAGATE-ST31000640SS-0003-931.51GB) Promise Jbod
c0t5000C500103E9FFBd0 ONLINE 0 0
0(SEAGATE-ST31000640SS-0003-931.51GB) Promise Jbod
c0t5000C500103E370Fd0 ONLINE 0 0
0(SEAGATE-ST31000640SS-0003-931.51GB) Promise Jbod
c0t5000C500103E120Fd0 ONLINE 0 0
0(SEAGATE-ST31000640SS-0003-931.51GB) Promise Jbod
logs
mirror-1 ONLINE 0 0 0
c0t500151795955D430d0 ONLINE 0 0 0(ATA-INTEL
SSDSA2VP02-02M5-18.64GB) onboard drive on x4140
c0t500151795955BDB6d0 ONLINE 0 0 0
(ATA-INTEL SSDSA2VP02-02M5-18.64GB)onboard drive on x4140
cache
c0t5001517BB271845Dd0 ONLINE 0 0 0
(ATA-INTEL SSDSA2CW16-0362-149.05GB)onboard drive on x4140
spares
c0t5000C500103E368Fd0 AVAIL
(SEAGATE-ST31000640SS-0003-931.51GB) Promise Jbod
The drives are in an external promise 12 drive jbod. The jbod is also
connected to another server that uses the other 6 SEAGATE ST31000640SS
drives.
This on Solaris 10 8/11 (Generic_147441-01). I'm using LSI 9200 for the
external promise jbod and an internal 9200 for the zli and l2arc which
also uses rpool.
FW versions on both cards are MPTFW-12.00.00.00-IT and MPT2BIOS-7.23.01.00.
I'm wondering why the zfs send could be so slow. Could the other server
be slowing down the sas bus?
Karl
CONFIDENTIALITY NOTICE: This communication (including all attachments) is
confidential and is intended for the use of the named addressee(s) only and
may contain information that is private, confidential, privileged, and
exempt from disclosure under law. All rights to privilege are expressly
claimed and reserved and are not waived. Any use, dissemination,
distribution, copying or disclosure of this message and any attachments, in
whole or in part, by anyone other than the intended recipient(s) is strictly
prohibited. If you have received this communication in error, please notify
the sender immediately, delete this communication from all data storage
devices and destroy all hard copies.
</pre>Karl Rossing2012-05-07T16:45:54Has anyone used a Dell with a PERC H310?
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49118
<pre>I'm trying to configure a DELL R720 (not a pleasant experience) which
has an H710p card fitted.
The H710p definitely doesn't support JBOD, but the H310 looks like it
might (the data sheet mentions non-RAID). Has anyone used one with ZFS?
Thanks,
</pre>Ian Collins2012-05-07T01:26:58Hung zfs destroy
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49113
<pre>On a Solaris 11 (SR3) system I have a zfs destroy process what appears
to be doing nothing and can't be killed. It has used 5 seconds of CPU
in a day and a half, but truss -p won't attach. No data appears to have
been removed. The dataset (but not the pool) is busy.
I thought this was an old problem that was fixed long ago in Solaris 10
(I had several temporary patches over the years), but it appears to be
alive and well.
Any hints?
</pre>Ian Collins2012-05-05T05:49:43ZFS performance on LSI 9240-8i?
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49104
<pre>Hi all,
I have a bad bad problem with our brand new server!
The lengthy details are below but to cut the story short, on the same
hardware (3 x LSI 9240-8i, 20 x 3TB 6gb HDDs) I am getting ZFS
sequential writes of 1.4GB/s on Solaris 10 (20 disks, 10 mirrors) and
only 200-240MB/s on latest Solaris 11.11 (same zpool config). By
writing directly to raw disks I found that in S10 the speed is 140MB/s
sequential writes per disk (consistent with combined 1.4GB/s for my
zpool) whereas only 24MB/s in Solaris 11 (consistent with 240MB/s
zpool, 10 mirrors 24MB/s each).
This must be the controller drivers, right? I downloaded drivers
version 4.7 off LSI site (says "for Solaris 10 and later") - they
failed to attach on S11. Version 3.03 worked but the system would
randomly crash, so I moved my experiments off S11 to S10. However, S10
has only the old implementation if iSCSI which gives me other problems
so I decided to give S11 another go.
Would there be any advice in this community?
Many thanks!
Roman
==============
root< at >carbon:~# echo | format | grep Hitachi
1. c5t8d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
2. c5t9d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
3. c5t10d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
4. c5t11d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
5. c5t13d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
6. c5t14d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
7. c5t15d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
9. c6t9d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
10. c6t10d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
11. c6t11d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
12. c6t13d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
13. c6t14d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
14. c6t15d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
15. c7t8d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
17. c7t10d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
18. c7t11d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
19. c7t12d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
20. c7t13d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
21. c7t14d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
22. c7t15d1 <ATA-Hitachi HUA72303-A5C0-2.73TB>
Reading DD from all disks:
(dd of=/dev/null bs=1024kb if=/dev/rdsk/c7t9d1 &)
# Iostat –xznM 2
extended device statistics
r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
614.5 0.0 153.6 0.0 0.0 1.0 0.0 1.6 0 98 c5t8d1
595.5 0.0 148.9 0.0 0.0 1.0 0.0 1.7 0 99 c7t8d1
1566.5 0.0 391.6 0.0 0.0 1.0 0.0 0.6 1 96 c6t8d1 # (SSD)
618.5 0.0 154.6 0.0 0.0 1.0 0.0 1.6 0 99 c6t9d1
616.5 0.0 154.1 0.0 0.0 1.0 0.0 1.6 0 99 c5t9d1
1564.0 0.0 391.0 0.0 0.0 1.0 0.0 0.6 1 96 c7t9d1# (SSD)
616.0 0.0 154.0 0.0 0.0 1.0 0.0 1.6 0 98 c7t10d1
554.0 0.0 138.5 0.0 0.0 1.0 0.0 1.8 0 99 c6t10d1
598.5 0.0 149.6 0.0 0.0 1.0 0.0 1.7 0 99 c5t10d1
588.5 0.0 147.1 0.0 0.0 1.0 0.0 1.7 0 98 c6t11d1
590.5 0.0 147.6 0.0 0.0 1.0 0.0 1.7 0 98 c7t11d1
591.5 0.0 147.9 0.0 0.0 1.0 0.0 1.7 0 99 c5t11d1
600.5 0.0 150.1 0.0 0.0 1.0 0.0 1.6 0 98 c6t13d1
617.5 0.0 154.4 0.0 0.0 1.0 0.0 1.6 0 99 c7t12d1
611.0 0.0 152.8 0.0 0.0 1.0 0.0 1.6 0 99 c5t13d1
625.0 0.0 156.3 0.0 0.0 1.0 0.0 1.6 0 99 c6t14d1
592.5 0.0 148.1 0.0 0.0 1.0 0.0 1.7 0 99 c7t13d1
596.0 0.0 149.0 0.0 0.0 1.0 0.0 1.7 0 99 c5t14d1
598.5 0.0 149.6 0.0 0.0 1.0 0.0 1.6 0 98 c6t15d1
618.5 0.0 154.6 0.0 0.0 1.0 0.0 1.6 0 98 c7t14d1
606.5 0.0 151.6 0.0 0.0 1.0 0.0 1.6 0 98 c5t15d1
625.0 0.0 156.3 0.0 0.0 1.0 0.0 1.6 0 98 c7t15d1
extended device statistics
r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
620.5 0.0 155.1 0.0 0.0 1.0 0.0 1.6 0 99 c5t8d1
620.5 0.0 155.1 0.0 0.0 1.0 0.0 1.6 0 99 c7t8d1
1581.0 0.0 395.2 0.0 0.0 1.0 0.0 0.6 1 96 c6t8d1
611.5 0.0 152.9 0.0 0.0 1.0 0.0 1.6 0 99 c6t9d1
587.5 0.0 146.9 0.0 0.0 1.0 0.0 1.7 0 99 c5t9d1
1580.0 0.0 395.0 0.0 0.0 1.0 0.0 0.6 1 97 c7t9d1
593.0 0.0 148.2 0.0 0.0 1.0 0.0 1.7 0 99 c7t10d1
616.0 0.0 154.0 0.0 0.0 1.0 0.0 1.6 0 99 c6t10d1
601.0 0.0 150.2 0.0 0.0 1.0 0.0 1.6 0 99 c5t10d1
587.0 0.0 146.7 0.0 0.0 1.0 0.0 1.7 0 99 c6t11d1
578.5 0.0 144.6 0.0 0.0 1.0 0.0 1.7 0 99 c7t11d1
624.5 0.0 156.1 0.0 0.0 1.0 0.0 1.6 0 99 c5t11d1
604.5 0.0 151.1 0.0 0.0 1.0 0.0 1.6 0 99 c6t13d1
573.5 0.0 143.4 0.0 0.0 1.0 0.0 1.7 0 99 c7t12d1
609.0 0.0 152.2 0.0 0.0 1.0 0.0 1.6 0 99 c5t13d1
630.5 0.0 157.6 0.0 0.0 1.0 0.0 1.6 0 99 c6t14d1
618.5 0.0 154.6 0.0 0.0 1.0 0.0 1.6 0 99 c7t13d1
633.5 0.0 158.4 0.0 0.0 1.0 0.0 1.6 0 99 c5t14d1
602.5 0.0 150.6 0.0 0.0 1.0 0.0 1.6 0 99 c6t15d1
589.5 0.0 147.4 0.0 0.0 1.0 0.0 1.7 0 99 c7t14d1
603.0 0.0 150.7 0.0 0.0 1.0 0.0 1.6 0 99 c5t15d1
586.0 0.0 146.5 0.0 0.0 1.0 0.0 1.7 0 99 c7t15d1
WRITING ZEROS TO RAW DISKS
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c6t9d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c5t9d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c7t8d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c6t10d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c7t10d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c5t10d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c6t11d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c5t11d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c7t11d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c6t13d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c7t12d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c5t13d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c6t14d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c5t14d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c7t13d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c6t15d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c7t14d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c5t15d1 &
root< at >carbon:~# dd if=/dev/zero bs=1024kb of=/dev/rdsk/c7t15d1 &
extended device statistics
r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c5t8d1
0.0 97.5 0.0 24.4 0.0 1.0 0.0 9.9 0 96 c7t8d1
0.0 98.0 0.0 24.5 0.0 1.0 0.0 10.2 0 100 c6t9d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c5t9d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c7t10d1
0.0 99.0 0.0 24.8 0.0 1.0 0.0 10.1 0 100 c6t10d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c5t10d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c6t11d1
0.0 99.0 0.0 24.8 0.0 1.0 0.0 10.1 0 100 c7t11d1
0.0 97.5 0.0 24.4 0.0 1.0 0.0 10.2 0 100 c5t11d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c6t13d1
0.0 98.5 0.0 24.6 0.0 1.0 0.0 10.1 0 100 c7t12d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c5t13d1
0.0 101.0 0.0 25.2 0.0 1.0 0.0 9.9 0 100 c6t14d1
0.0 101.5 0.0 25.4 0.0 1.0 0.0 9.8 0 100 c7t13d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c5t14d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c6t15d1
0.0 99.0 0.0 24.7 0.0 1.0 0.0 10.1 0 100 c7t14d1
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c5t15d1
0.0 101.0 0.0 25.2 0.0 1.0 0.0 9.9 0 100 c7t15d1
extended device statistics
r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c5t8d1
0.0 101.0 0.0 25.3 0.0 1.0 0.0 9.9 0 100 c7t8d1
0.0 98.0 0.0 24.5 0.0 1.0 0.0 10.2 0 100 c6t9d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c5t9d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c7t10d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c6t10d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c5t10d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c6t11d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c7t11d1
0.0 94.5 0.0 23.6 0.0 1.0 0.0 10.2 0 96 c5t11d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c6t13d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c7t12d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c5t13d1
0.0 97.0 0.0 24.3 0.0 1.0 0.0 9.9 0 96 c6t14d1
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c7t13d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c5t14d1
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c6t15d1
0.0 99.0 0.0 24.8 0.0 1.0 0.0 10.1 0 100 c7t14d1
0.0 96.5 0.0 24.1 0.0 1.0 0.0 10.0 0 96 c5t15d1
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c7t15d1
extended device statistics
r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
0.0 101.5 0.0 25.4 0.0 1.0 0.0 9.8 0 100 c5t8d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c7t8d1
0.0 97.5 0.0 24.4 0.0 1.0 0.0 10.2 0 100 c6t9d1
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c5t9d1
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c7t10d1
0.0 101.5 0.0 25.4 0.0 1.0 0.0 9.8 0 100 c6t10d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c5t10d1
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c6t11d1
0.0 98.5 0.0 24.6 0.0 1.0 0.0 10.1 0 100 c7t11d1
0.0 98.0 0.0 24.5 0.0 1.0 0.0 10.2 0 100 c5t11d1
0.0 101.0 0.0 25.3 0.0 1.0 0.0 9.9 0 100 c6t13d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c7t12d1
0.0 101.0 0.0 25.3 0.0 1.0 0.0 9.9 0 100 c5t13d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c6t14d1
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c7t13d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c5t14d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c6t15d1
0.0 99.5 0.0 24.9 0.0 1.0 0.0 10.0 0 100 c7t14d1
0.0 100.5 0.0 25.1 0.0 1.0 0.0 9.9 0 100 c5t15d1
0.0 100.0 0.0 25.0 0.0 1.0 0.0 10.0 0 100 c7t15d1
**************
Only 25MB/s!!!
**************
Testing ZPOOL
zpool create data mirror
zpool create data \
mirror c5t8d1 c6t9d1 mirror c5t9d1 c7t8d1 mirror c6t10d1 c7t10d1 \
mirror c5t10d1 c6t11d1 mirror c5t11d1 c7t11d1 mirror c6t13d1 c7t12d1 \
mirror c5t13d1 c6t14d1 mirror c5t14d1 c7t13d1 mirror c6t15d1 c7t14d1 \
mirror c5t15d1 c7t15d1
root< at >carbon:~#
root< at >carbon:~# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c5t8d1 ONLINE 0 0 0
c6t9d1 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c5t9d1 ONLINE 0 0 0
c7t8d1 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
c6t10d1 ONLINE 0 0 0
c7t10d1 ONLINE 0 0 0
mirror-3 ONLINE 0 0 0
c5t10d1 ONLINE 0 0 0
c6t11d1 ONLINE 0 0 0
mirror-4 ONLINE 0 0 0
c5t11d1 ONLINE 0 0 0
c7t11d1 ONLINE 0 0 0
mirror-5 ONLINE 0 0 0
c6t13d1 ONLINE 0 0 0
c7t12d1 ONLINE 0 0 0
mirror-6 ONLINE 0 0 0
c5t13d1 ONLINE 0 0 0
c6t14d1 ONLINE 0 0 0
mirror-7 ONLINE 0 0 0
c5t14d1 ONLINE 0 0 0
c7t13d1 ONLINE 0 0 0
mirror-8 ONLINE 0 0 0
c6t15d1 ONLINE 0 0 0
c7t14d1 ONLINE 0 0 0
mirror-9 ONLINE 0 0 0
c5t15d1 ONLINE 0 0 0
c7t15d1 ONLINE 0 0 0
errors: No known data errors
root< at >carbon:~#
==========================================================
Writing to file
==========================================================
root< at >carbon:~# dd if=/dev/zero of=/data/testfile bs=1024kb
root< at >carbon:~# dd if=/dev/zero of=/data/testfile bs=128kb
data 3.93M 27.2T 0 1.46K 102 179M
data 3.93M 27.2T 0 263 0 30.1M
data 1.02G 27.2T 0 456 0 56.3M
data 2.04G 27.2T 0 2.11K 0 263M
data 3.02G 27.2T 0 1.62K 0 202M
data 3.97G 27.2T 0 1.38K 0 171M
data 4.90G 27.2T 0 1.96K 0 245M
data 5.80G 27.2T 0 826 0 99.5M
data 5.80G 27.2T 0 755 0 92.9M
data 6.67G 27.2T 0 992 0 120M
data 7.53G 27.2T 0 1.49K 0 185M
data 8.36G 27.2T 0 1.13K 0 141M
********
250MB/s consistent with ten mirrors 25MB/s each (see individual disk
write test above).
********
#############################################################
SCSI CARD – LSI 9240-8i
SCSI CARD DRIVER (imraid_sas)
Solaris: SunOS carbon 5.11 11.0 i86pc i386 i86pc
#############################################################
root< at >carbon:~# grep 9240 /etc/path_to_inst
"/pci< at >0,0/pci15ad,7a0< at >15/pci1000,9240< at >0" 0 "imraid_sas"
"/pci< at >0,0/pci15ad,7a0< at >15/pci1000,9240< at >0/sd< at >8,1" 2 "sd"
"/pci< at >0,0/pci15ad,7a0< at >15/pci1000,9240< at >0/sd< at >9,1" 6 "sd"
"/pci< at >0,0/pci15ad,7a0< at >15/pci1000,9240< at >0/sd< at >a,1" 10 "sd"
"/pci< at >0,0/pci15ad,7a0< at >15/pci1000,9240< at >0/sd< at >b,1" 13 "sd"
"/pci< at >0,0/pci15ad,7a0< at >15/pci1000,9240< at >0/sd< at >d,1" 16 "sd"
"/pci< at >0,0/pci15ad,7a0< at >15/pci1000,9240< at >0/sd< at >e,1" 19 "sd"
"/pci< at >0,0/pci15ad,7a0< at >15/pci1000,9240< at >0/sd< at >f,1" 22 "sd"
"/pci< at >0,0/pci15ad,7a0< at >16/pci1000,9240< at >0" 1 "imraid_sas"
"/pci< at >0,0/pci15ad,7a0< at >16/pci1000,9240< at >0/sd< at >8,1" 4 "sd"
"/pci< at >0,0/pci15ad,7a0< at >16/pci1000,9240< at >0/sd< at >9,1" 5 "sd"
"/pci< at >0,0/pci15ad,7a0< at >16/pci1000,9240< at >0/sd< at >a,1" 9 "sd"
"/pci< at >0,0/pci15ad,7a0< at >16/pci1000,9240< at >0/sd< at >b,1" 11 "sd"
"/pci< at >0,0/pci15ad,7a0< at >16/pci1000,9240< at >0/sd< at >d,1" 14 "sd"
"/pci< at >0,0/pci15ad,7a0< at >16/pci1000,9240< at >0/sd< at >e,1" 17 "sd"
"/pci< at >0,0/pci15ad,7a0< at >16/pci1000,9240< at >0/sd< at >f,1" 20 "sd"
"/pci< at >0,0/pci15ad,7a0< at >17/pci1000,9240< at >0" 2 "imraid_sas"
"/pci< at >0,0/pci15ad,7a0< at >17/pci1000,9240< at >0/sd< at >8,1" 3 "sd"
"/pci< at >0,0/pci15ad,7a0< at >17/pci1000,9240< at >0/sd< at >9,1" 7 "sd"
"/pci< at >0,0/pci15ad,7a0< at >17/pci1000,9240< at >0/sd< at >a,1" 8 "sd"
"/pci< at >0,0/pci15ad,7a0< at >17/pci1000,9240< at >0/sd< at >b,1" 12 "sd"
"/pci< at >0,0/pci15ad,7a0< at >17/pci1000,9240< at >0/sd< at >c,1" 15 "sd"
"/pci< at >0,0/pci15ad,7a0< at >17/pci1000,9240< at >0/sd< at >d,1" 18 "sd"
"/pci< at >0,0/pci15ad,7a0< at >17/pci1000,9240< at >0/sd< at >e,1" 21 "sd"
"/pci< at >0,0/pci15ad,7a0< at >17/pci1000,9240< at >0/sd< at >f,1" 23 "sd"
root< at >carbon:~# grep imraid /etc/driver_aliases
imraid_sas "pciex1000,73"
#############################################################
</pre>Roman Matiyenko2012-05-04T12:25:07autoexpand in a physical disk with 2 zpool
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49092
<pre>Hi,
I a Solaris 10 Update 10 box with 1 disk which is used for two different
zpool:
root< at >sct-jordi-02:~# cat /etc/release
Oracle Solaris 10 8/11 s10x_u10wos_17b X86
Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights
reserved.
Assembled 23 August 2011
root< at >sct-jordi-02:~# echo | format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0 <DEFAULT cyl 7829 alt 2 hd 255 sec 63>
/pci< at >0,0/pci15ad,1976< at >10/sd< at >0,0
Specify disk (enter its number): Specify disk (enter its number):
root< at >sct-jordi-02:~# zpool iostat -v
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
opt 290M 29.5G 0 0 213 5.33K
c0t0d0s7 290M 29.5G 0 0 213 5.33K
---------- ----- ----- ----- ----- ----- -----
rpool 13.7G 16.3G 0 3 14.4K 53.8K
c0t0d0s0 13.7G 16.3G 0 3 14.4K 53.8K
---------- ----- ----- ----- ----- ----- -----
root< at >sct-jordi-02:~# zpool get all rpool opt
NAME PROPERTY VALUE SOURCE
opt size 29.8G -
opt capacity 0% -
opt altroot - default
opt health ONLINE -
opt guid 13450764434721172659 default
opt version 29 default
opt bootfs - default
opt delegation on default
opt autoreplace off default
opt cachefile - default
opt failmode wait default
opt listsnapshots on default
opt autoexpand off default
opt free 29.5G -
opt allocated 290M -
opt readonly off -
rpool size 30G -
rpool capacity 45% -
rpool altroot - default
rpool health ONLINE -
rpool guid 16899781381017818003 default
rpool version 29 default
rpool bootfs rpool/ROOT/s10_u10 local
rpool delegation on default
rpool autoreplace off default
rpool cachefile - default
rpool failmode continue local
rpool listsnapshots on default
rpool autoexpand on local
rpool free 16.3G -
rpool allocated 13.7G -
rpool readonly off -
Note, as you can see, the slice 0 i used for 'rpool' and the slice 7 is
used for 'opt'. The autoexpand propierty is enabled in 'rpool' but is
disabled in 'opt'
This machine is a virtual one (VMware), so I can enlarge the disk easily
if I need. Let's say I enlarge the disk 10 GB:
# Before enlarge the disk
root< at >sct-jordi-02:~# echo | format ; df -h
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0 <DEFAULT cyl 7829 alt 2 hd 255 sec 63>
/pci< at >0,0/pci15ad,1976< at >10/sd< at >0,0
Specify disk (enter its number): Specify disk (enter its number):
Filesystem size used avail capacity Mounted on
rpool/ROOT/s10_u10 30G 5.7G 7.3G 44% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 10G 328K 10G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/usr/lib/libc/libc_hwcap2.so.1
13G 5.7G 7.3G 44% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 10G 36K 10G 1% /tmp
swap 10G 40K 10G 1% /var/run
rpool/export 30G 32K 7.3G 1% /export
rpool/export/home 30G 31K 7.3G 1% /export/home
opt 29G 290M 29G 1% /opt
opt/zones 29G 31K 29G 1% /opt/zones
rpool 30G 42K 7.3G 1% /rpool
# After enlarge the disk 10GB
root< at >sct-jordi-02:~# devfsadm
root< at >sct-jordi-02:~# echo | format ; df -h
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0 <DEFAULT cyl 7829 alt 2 hd 255 sec 63>
/pci< at >0,0/pci15ad,1976< at >10/sd< at >0,0
Specify disk (enter its number): Specify disk (enter its number):
Filesystem size used avail capacity Mounted on
rpool/ROOT/s10_u10 30G 5.7G 7.3G 44% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 10G 328K 10G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/usr/lib/libc/libc_hwcap2.so.1
13G 5.7G 7.3G 44% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 10G 44K 10G 1% /tmp
swap 10G 40K 10G 1% /var/run
rpool/export 30G 32K 7.3G 1% /export
rpool/export/home 30G 31K 7.3G 1% /export/home
opt 29G 290M 29G 1% /opt
opt/zones 29G 31K 29G 1% /opt/zones
rpool 30G 42K 7.3G 1% /rpool
The size of rpool zpool stills the same.
How to do it?
PS. I know perfectly how to expand any zpool just adding a new device;
actually I think is even better, but that's not the point.
</pre>Jordi Espasa Clofent2012-05-03T05:44:19IOzone benchmarking
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49068
<pre>I'm trying to run some IOzone benchmarking on a new system to get a
feel for baseline performance.
Unfortunately, the system has a lot of memory (144GB), but I have some
time so am approaching my runs as follows:
Throughput:
iozone -m -t 8 -T -r 128k -o -s 36G -R -b bigfile.xls
IOPS:
iozone -O -i 0 -i 1 -i 2 -e -+n -r 128K -s 288G > iops.txt
Not sure what I gain/lose by using threads or not.
Am I off on this?
System is a 240x2TB (7200RPM) system in 20 Dell MD1200 JBODs. 16 vdevs of 15
disks each -- RAIDZ3. NexentaStor 3.1.2.
Ray
</pre>Ray Van Dolson2012-04-30T20:15:07ZFS on Linux vs FreeBSD
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/49009
<pre>This may fall into the realm of a religious war (I hope not!), but recently
several people on this list have said/implied that ZFS was only acceptable for
production use on FreeBSD (or Solaris, of course) rather than Linux with ZoL.
I'm working on a project at work involving a large(-ish) amount of data, about
5TB, working its way up to 12-15TB eventually, spread among a dozen or so
nodes. There may or may not be a clustered filesystem involved (probably
gluster if we use anything). I've been looking at ZoL as the primary
filesystem for this data. We're a Linux shop, so I'd rather not switch to
FreeBSD, or any of the Solaris-derived distros--although I have no problem
with them, I just don't want to introduce another OS into the mix if I can
avoid it.
So, the actual questions are:
Is ZoL really not ready for production use?
If not, what is holding it back? Features? Performance? Stability?
If not, then what kind of timeframe are we looking at to get past whatever is
holding it back?
</pre>Paul Archer2012-04-25T12:48:57Search EngineSearch the mailing list at Gmanequery
http://search.gmane.org/?group=$group=gmane.os.solaris.opensolaris.zfs