Hi,
Just be reading about apache.org incident report for 8/28/2009
( https://blogs.apache.org/infra/entry/apache_org_downtime_report )
The use of Solaris and ZFS on the European server was interesting including the
recovery.
However, what I found more interesting was the use of one time
Let me explain what i have and you decide if it's what you're looking for.
I run a home NAS based on ZFS (due to hardware issues i am using FreeBSD 7.2
as my os but all the data is on ZFS)
This system has multiple uses. I have about 10 users and 4 HTPC's connected
via gigabit. I have ZFS
Scott Lawson writes:
Also you may wish to look at the output of 'iostat -xnce 1' as well.
You can post those to the list if you have a specific problem.
You want to be looking for error counts increasing and specifically 'asvc_t'
for the service times on the disks. I higher number
Do you have the zfs primarycache property on this release ?
if so, you could set it to 'metadata' or none.
primarycache=all | none | metadata
Controls what is cached in the primary cache (ARC). If
this property is set to all, then both user data and
metadata
Bill Moore Bill.Moore at sun.com writes:
Moving on, modern high-capacity SATA drives are in the 100-120MB/s
range. Let's call it 125MB/s for easier math. A 5-port port multiplier
(PM) has 5 links to the drives, and 1 uplink. SATA-II speed is 3Gb/s,
which after all the framing overhead,
Marc Bevand m.bevand at gmail.com writes:
So in conclusion, my SBNSWAG (scientific but not so wild-ass guess)
is that the max I/O throughput when reading from all the disks on
1 of their storage pod is about 1000MB/s.
Correction: the SiI3132 are on x1 (not x2) links, so my guess as to
the
100% random writes produce around 200 IOPS with a 4-6 second pause
around every 10 seconds.
This indicates that the bandwidth you're able to transfer
through the protocol is about 50% greater than the bandwidth
the pool can offer to ZFS. Since, this is is not sustainable, you
stuart anderson writes:
Question :
Is there a way to change the volume blocksize
say
via 'zfs snapshot send/receive'?
As I see things, this isn't possible as the
target
volume (including property values) gets
overwritten
by 'zfs receive'.
Lori Alt wrote:
The -n option does some verification. It verifies that the record
headers distributed throughout the stream are syntactically valid.
Since each record header contains a length field which allows the next
header to be found, one bad header will cause the processing of the
Roch Bourbonnais Wrote:
100% random writes produce around 200 IOPS with a 4-6 second pause
around every 10 seconds.
This indicates that the bandwidth you're able to transfer
through the protocol is about 50% greater than the bandwidth
the pool can offer to ZFS. Since, this is is not sustainable,
On 09/04/09 09:41, dick hoogendijk wrote:
Lori Alt wrote:
The -n option does some verification. It verifies that the record
headers distributed throughout the stream are syntactically valid.
Since each record header contains a length field which allows the
next header to be found, one bad
Hi zfs congnoscenti,
a few quick question about my hardware choice (a bit late, since the
box is up already):
A 3U supermicro chassis with 16x SATA/SAS hotplug
Supermicro X8DDAi (2x Xeon QC 1.26 GHz S1366, 24 GByte RAM, IPMI)
2x LSI SAS3081E-R
16x WD2002FYPS
Right now I'm running Solaris 10
On Sep 3, 2009, at 10:32 PM, Tim Cook wrote:
On Fri, Sep 4, 2009 at 12:17 AM, Ross myxi...@googlemail.com wrote:
Hi Richard,
Actually, reading your reply has made me realise I was overlooking
something when I talked about tar, star, etc... How do you backup a
ZFS volume? That's something
Lori Alt wrote:
The -u option to zfs recv (which was just added to support flash
archive installs, but it's useful for other reasons too) suppresses
all mounts of the received file systems. So you can mount them
yourself afterward in whatever order is appropriate, or do a 'zfs
mount -a'.
You
On 09/04/09 09:54, Scott Meilicke wrote:
Roch Bourbonnais Wrote:
100% random writes produce around 200 IOPS with a 4-6 second pause
around every 10 seconds.
This indicates that the bandwidth you're able to transfer
through the protocol is about 50% greater than the bandwidth
the pool
This sounds like the same behavior as opensolaris 2009.06. I had several disks
recently go UNAVAIL, and the spares did not take over. But as soon as I
physically removed a disk, the spare started replacing the removed disk. It
seems UNAVAIL is not the same as the disk not being there. I wish
Scott Meilicke wrote:
So what happens during the txg commit?
For example, if the ZIL is a separate device, SSD for this example, does it
not work like:
1. A sync operation commits the data to the SSD
2. A txg commit happens, and the data from the SSD are written to the
spinning disk
So what happens during the txg commit?
For example, if the ZIL is a separate device, SSD for this example, does it not
work like:
1. A sync operation commits the data to the SSD
2. A txg commit happens, and the data from the SSD are written to the spinning
disk
So this is two writes, correct?
We have a number of shared spares configured in our ZFS pools, and
we're seeing weird issues where spares don't get used under some
circumstances. We're running Solaris 10 U6 using pools made up of
mirrored vdevs, and what I've seen is:
* if ZFS detects enough checksum errors on an active disk,
Doh! I knew that, but then forgot...
So, for the case of no separate device for the ZIL, the ZIL lives on the disk
pool. In which case, the data are written to the pool twice during a sync:
1. To the ZIL (on disk)
2. From RAM to disk during tgx
If this is correct (and my history in this
On Fri, 4 Sep 2009, Scott Meilicke wrote:
So what happens during the txg commit?
For example, if the ZIL is a separate device, SSD for this example, does it not
work like:
1. A sync operation commits the data to the SSD
2. A txg commit happens, and the data from the SSD are written to the
So, I just re-read the thread, and you can forget my last post. I had thought
the argument was that the data were not being written to disk twice (assuming
no separate device for the ZIL), but it was just explaining to me that the data
are not read from the ZIL to disk, but rather from memory
On Fri, Sep 4, 2009 at 5:36 AM, Marc Bevand m.bev...@gmail.com wrote:
Marc Bevand m.bevand at gmail.com writes:
So in conclusion, my SBNSWAG (scientific but not so wild-ass guess)
is that the max I/O throughput when reading from all the disks on
1 of their storage pod is about 1000MB/s.
Scott Meilicke wrote:
I am still not buying it :) I need to research this to satisfy myself.
I can understand that the writes come from memory to disk during a txg write
for async, and that is the behavior I see in testing.
But for sync, data must be committed, and a SSD/ZIL makes that faster
We have groups generating terabytes a day of image data from lab instruments
and saving them to an X4500.
We have tried lzbj : compressratio = 1.13 in 11 hours , 1.3 TB - 1.1 TB
gzip -9 : compress ratio = 1.68 in 37 hours, 1.3 TB -
.75 TB
The filesystem performance was
On Wed, Sep 2, 2009 at 4:56 PM, David Magdadma...@ee.ryerson.ca wrote:
Said support was committed only two to three weeks ago:
PSARC/2009/394 SATA Framework Port Multiplier Support
6422924 sata framework has to support port multipliers
6691950 ahci driver needs to support SIL3726/4726 SATA
On Sep 4, 2009, at 2:22 PM, Scott Meilicke scott.meili...@craneaerospace.com
wrote:
So, I just re-read the thread, and you can forget my last post. I
had thought the argument was that the data were not being written to
disk twice (assuming no separate device for the ZIL), but it was
just
Yes, I was getting confused. Thanks to you (and everyone else) for clarifying.
Sync or async, I see the txg flushing to disk starve read IO.
Scott
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
On Sep 4, 2009, at 12:23 PM, Len Zaifman wrote:
We have groups generating terabytes a day of image data from lab
instruments and saving them to an X4500.
Wouldn't it be easier to compress at the application, or between the
application and the archiving file system?
We have tried lzbj :
On Sep 4, 2009, at 4:33 PM, Scott Meilicke scott.meili...@craneaerospace.com
wrote:
Yes, I was getting confused. Thanks to you (and everyone else) for
clarifying.
Sync or async, I see the txg flushing to disk starve read IO.
Well try the kernel setting and see how it helps.
Honestly
On Fri, 2009-09-04 at 13:41 -0700, Richard Elling wrote:
On Sep 4, 2009, at 12:23 PM, Len Zaifman wrote:
We have groups generating terabytes a day of image data from lab
instruments and saving them to an X4500.
Wouldn't it be easier to compress at the application, or between the
I only see the blocking while load testing, not during regular usage, so I am
not so worried. I will try the kernel settings to see if that helps if/when I
see the issue in production.
For what it is worth, here is the pattern I see when load testing NFS (iometer,
60% random, 65% read, 8k
On Fri, Sep 04, 2009 at 01:41:15PM -0700, Richard Elling wrote:
On Sep 4, 2009, at 12:23 PM, Len Zaifman wrote:
We have groups generating terabytes a day of image data from lab
instruments and saving them to an X4500.
Wouldn't it be easier to compress at the application, or between the
On 09/04/09 10:17, dick hoogendijk wrote:
Lori Alt wrote:
The -u option to zfs recv (which was just added to support flash
archive installs, but it's useful for other reasons too) suppresses
all mounts of the received file systems. So you can mount them
yourself afterward in whatever order
On Fri, 4 Sep 2009, Louis-Frédéric Feuillette wrote:
JPEG2000 uses arithmetic encoding to do the final compression step.
Arithmetic encoding has a higher compression rate (in general) than
gzip-9, lzbj or others. There is an opensource implementation of
jpeg2000 called jasper[1]. Jasper is
On Fri, 4 Sep 2009, Scott Meilicke wrote:
I only see the blocking while load testing, not during regular
usage, so I am not so worried. I will try the kernel settings to see
if that helps if/when I see the issue in production.
The flipside of the pulsing is that the deferred writes dimish
On Sep 4, 2009, at 6:33 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us
wrote:
On Fri, 4 Sep 2009, Scott Meilicke wrote:
I only see the blocking while load testing, not during regular
usage, so I am not so worried. I will try the kernel settings to
see if that helps if/when I see the
On Sep 4, 2009, at 5:25 PM, Scott Meilicke scott.meili...@craneaerospace.com
wrote:
I only see the blocking while load testing, not during regular
usage, so I am not so worried. I will try the kernel settings to see
if that helps if/when I see the issue in production.
For what it is
On Fri, Sep 4, 2009 at 1:12 PM, Nigel
Smithnwsm...@wilusa.freeserve.co.uk wrote:
Let us know if you can get the port multipliers working..
But remember, there is a problem with ZFS raidz in that release, so be
careful:
I saw that, so I think I'll be waiting until snv_124 to update. The
On Fri, 4 Sep 2009, Ross Walker wrote:
I guess one can find a silver lining in any grey cloud, but for myself I'd
just rather see a more linear approach to writes. Anyway I have never seen
any reads happen during these write flushes.
I have yet to see a read happen during the write flush
On Sep 4, 2009, at 8:59 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us
wrote:
On Fri, 4 Sep 2009, Ross Walker wrote:
I guess one can find a silver lining in any grey cloud, but for
myself I'd just rather see a more linear approach to writes. Anyway
I have never seen any reads happen
On Fri, 4 Sep 2009, Ross Walker wrote:
I have yet to see a read happen during the write flush either. That
impacts my application since it needs to read in order to proceed, and it
does a similar amount of writes as it does reads.
The ARC makes it hard to tell if they are satisfied from
On Sep 4, 2009, at 21:44, Ross Walker wrote:
Though I have only heard good comments from my ESX admins since
moving the VMs off iSCSI and on to ZFS over NFS, so it can't be that
bad.
What's your pool configuration? Striped mirrors? RAID-Z with SSDs?
Other?
On Sep 4, 2009, at 10:02 PM, David Magda dma...@ee.ryerson.ca wrote:
On Sep 4, 2009, at 21:44, Ross Walker wrote:
Though I have only heard good comments from my ESX admins since
moving the VMs off iSCSI and on to ZFS over NFS, so it can't be
that bad.
What's your pool configuration?
On Thu, Sep 3, 2009 at 4:57 AM, Karel Gardas karel.gar...@centrum.czwrote:
Hello,
your (open)solaris for Ecc support (which seems to have been dropped from
200906) is misunderstanding. OS 2009.06 also supports ECC as 2005 did. Just
install it and use my updated ecccheck.pl script to get
I've been sending daily incrementals off-site for a while now, but
recently they failed so I had to send an incremental covering a number
of snapshots. I expected the incremental to be approximately the sum
of the snapshots, but it seems to be considerably larger and still
going. The source
Tim Cook tim at cook.ms writes:
Whats the point of arguing what the back-end can do anyways? This is bulk
data storage. Their MAX input is ~100MB/sec. The backend can more than
satisfy that. Who cares at that point whether it can push 500MB/s or
5000MB/s? It's not a database processing
On Sat, Sep 5, 2009 at 12:30 AM, Marc Bevand m.bev...@gmail.com wrote:
Tim Cook tim at cook.ms writes:
Whats the point of arguing what the back-end can do anyways? This is
bulk
data storage. Their MAX input is ~100MB/sec. The backend can more than
satisfy that. Who cares at that point
48 matches
Mail list logo
