Try with this /etc/system tunings :
set mac:mac_soft_ring_thread_bind=0
set mac:mac_srs_thread_bind=0
set zfs:zio_taskq_batch_pct=50
Le 12 juin 2012 à 11:37, Roch Bourbonnais a écrit :
>
> So the xcall are necessary part of memory reclaiming, when one needs to tear
> down the
So the xcall are necessary part of memory reclaiming, when one needs to tear
down the TLB entry mapping the physical memory (which can from here on be
repurposed).
So the xcall are just part of this. Should not cause trouble, but they do. They
consume a cpu for some time.
That in turn can caus
The process should be scalable.
Scrub all of the data on one disk using one disk worth of IOPS
Scrub all of the data on N disks using N disk's worth of IOPS.
THat will take ~ the same total time.
-r
Le 12 juin 2012 à 08:28, Jim Klimov a écrit :
> 2012-06-12 16:20, Roch Bourbonna
Scrubs are run at very low priority and yield very quickly in the presence of
other work.
So I really would not expect to see scrub create any impact on an other type of
storage activity.
Resilvering will more aggressively push forward on what is has to do, but
resilvering does not need to
rea
Josh, I don't know the internals of the device but I have heard reports of SSDs
that would ignore flush write cache commands _and_ wouldn't have a supercap
protection (nor battery).
Such devices are subject to dataloss.
Did you also catch this thread
http://opensolaris.org/jive/thread
Le 5 août 2010 à 19:49, Ross Walker a écrit :
> On Aug 5, 2010, at 11:10 AM, Roch wrote:
>
>>
>> Ross Walker writes:
>>> On Aug 4, 2010, at 12:04 PM, Roch wrote:
>>>
Ross Walker writes:
> On Aug 4, 2010, at 9:20 AM, Roch wrote:
>
>>
>>
>> Ross Asks:
>>
Le 27 mai 2010 à 07:03, Brent Jones a écrit :
> On Wed, May 26, 2010 at 5:08 AM, Matt Connolly
> wrote:
>> I've set up an iScsi volume on OpenSolaris (snv_134) with these commands:
>>
>> sh-4.0# zfs create rpool/iscsi
>> sh-4.0# zfs set shareiscsi=on rpool/iscsi
>> sh-4.0# zfs create -s -V 10g
Can you post zpool status ?
Are your drives all the same size ?
-r
Le 30 mai 2010 à 23:37, Sandon Van Ness a écrit :
> I just wanted to make sure this is normal and is expected. I fully
> expected that as the file-system filled up I would see more disk space
> being used than with other file-sy
I think This is highlighting that there is extra CPU requirement to
manage small blocks in ZFS.
The table would probably turn over if you go to 16K zfs records and
16K reads/writes form the application.
Next step for you is to figure how much reads/writes IOPS do you
expect to take in the
Le 5 janv. 10 à 17:49, Robert Milkowski a écrit :
On 05/01/2010 16:00, Roch wrote:
That said, I truly am for a evolution for random read
workloads. Raid-Z on 4K sectors is quite appealing. It means
that small objects become nearly mirrored with good random read
performance while large objects
Le 28 déc. 09 à 00:59, Tim Cook a écrit :
On Sun, Dec 27, 2009 at 1:38 PM, Roch Bourbonnais > wrote:
Le 26 déc. 09 à 04:47, Tim Cook a écrit :
On Fri, Dec 25, 2009 at 11:57 AM, Saso Kiselkov
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've started porting a video s
Le 26 déc. 09 à 04:47, Tim Cook a écrit :
On Fri, Dec 25, 2009 at 11:57 AM, Saso Kiselkov
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've started porting a video streaming application to opensolaris on
ZFS, and am hitting some pretty weird performance issues. The thing
I'm
t
You might try setting zfs_scrub_limit to 1 or 2 and attach a customer
service record to :
6494473 ZFS needs a way to slow down resilvering
-r
Le 7 oct. 09 à 06:14, John a écrit :
Hi,
We are running b118, with a LSI 3801 controller which is connected
to 44 drives (yes it's a lo
Le 28 sept. 09 à 17:58, Glenn Fawcett a écrit :
Been there, done that, got the tee shirt A larger SGA will
*always* be more efficient at servicing Oracle requests for blocks.
You avoid going through all the IO code of Oracle and it simply
reduces to a hash.
Sounds like good advice
Le 23 sept. 09 à 19:07, Neil Perrin a écrit :
On 09/23/09 10:59, Scott Meilicke wrote:
How can I verify if the ZIL has been disabled or not? I am trying
to see how much benefit I might get by using an SSD as a ZIL. I
disabled the ZIL via the ZFS Evil Tuning Guide:
echo zil_disable/W0t1 |
Unlike NFS which can issue sync writes and async writes, iscsi needs
to be serviced with synchronous semantics (unless the write caching is
enabled, caveat emptor).
If the workloads issuing the iscsi request is single threaded, then
performance is governed by I/O size over rotational latenc
Le 5 août 09 à 06:06, Chookiex a écrit :
Hi All,
You know, ZFS afford a very Big buffer for write IO.
So, When we write a file, the first stage is put it to buffer.
But, if the file is VERY short-lived? Is it bring IO to disk?
or else, it just put the meta data and data to memory, and then
re
Try
zpool import 2169223940234886392 [storage1]
-r
Le 4 août 09 à 15:11, David a écrit :
I seem to have run into an issue with a pool I have, and haven't
found a resolution yet. The box is currently running FreeBSD 7-
STABLE with ZFS v13, (Open)Solaris doesn't support my raid controller.
Le 26 juil. 09 à 01:34, Toby Thain a écrit :
On 25-Jul-09, at 3:32 PM, Frank Middleton wrote:
On 07/25/09 02:50 PM, David Magda wrote:
Yes, it can be affected. If the snapshot's data structure / record
is
underneath the corrupted data in the tree then it won't be able to
be
reached.
Le 19 juil. 09 à 16:47, Bob Friesenhahn a écrit :
On Sun, 19 Jul 2009, Ross wrote:
The success of any ZFS implementation is *very* dependent on the
hardware you choose to run it on.
To clarify:
"The success of any filesystem implementation is *very* dependent on
the hardware you choose
Le 4 août 09 à 13:42, Joseph L. Casale a écrit :
does anybody have some numbers on speed on sata vs 15k sas?
The next chance I get, I will do a comparison.
Is it really a big difference?
I noticed a huge improvement when I moved a virtualized pool
off a series of 7200 RPM SATA discs to ev
The things I'd pay most attention to would be all single threaded 4K,
32K, and 128K writes to the raw device.
Maybe sure the SSD has a capacitor and enable the write cache on the
device.
-r
Le 5 juil. 09 à 12:06, James Lever a écrit :
On 04/07/2009, at 3:08 AM, Bob Friesenhahn wrote:
I
We're definitely working on problems contributing to such 'picket
fencing'.
But beware to equate symptoms and root caused issues. We already know
that picket fencing is multicause and
we're tracking the ones we know about : there is something related to
taskq cpu scheduling and
something
Le 18 juin 09 à 20:23, Richard Elling a écrit :
Cor Beumer - Storage Solution Architect wrote:
Hi Jose,
Well it depends on the total size of your Zpool and how often these
files are changed.
...and the average size of the files. For small files, it is likely
that the default
recordsize
Le 16 juin 09 à 19:55, Jose Martins a écrit :
Hello experts,
IHAC that wants to put more than 250 Million files on a single
mountpoint (in a directory tree with no more than 100 files on each
directory).
He wants to share such filesystem by NFS and mount it through
many Linux Debian clients
Le 6 févr. 09 à 20:54, Ross Smith a écrit :
Something to do with cache was my first thought. It seems to be able
to read and write from the cache quite happily for some time,
regardless of whether the pool is live.
If you're reading or writing large amounts of data, zfs starts
experiencing IO
Le 8 févr. 09 à 13:44, David Magda a écrit :
On Feb 8, 2009, at 16:12, Vincent Fox wrote:
Do you think having log on a 15K RPM drive with the main pool
composed of 10K RPM drives will show worthwhile improvements? Or am
I chasing a few percentage points?
Another important question is wheth
Le 8 févr. 09 à 13:12, Vincent Fox a écrit :
Thanks I think I get it now.
Do you think having log on a 15K RPM drive with the main pool
composed of 10K RPM drives will show worthwhile improvements? Or am
I chasing a few percentage points?
In cases where logzilla helps, then this shoul
Sounds like the device it not ignoring the cache flush requests sent
down by ZFS/zil commit.
If the SSD is able the drain it's internal buffer to flash on a power
outage; then it needs to ignore the cache flush.
You can do this on a per device basis, It's kludgy tuning but hope the
instructi
Le 12 janv. 09 à 17:39, Carson Gaspar a écrit :
> Joerg Schilling wrote:
>> Fabian Wörner wrote:
>>
>>> my post was not to start a discuss gpl<>cddl.
>>> It just an idea to promote ZFS and OPENSOLARIS
>>> If it was against anything than against exfat, nothing else!!!
>>
>> If you like to pro
Le 13 janv. 09 à 21:49, Orvar Korvar a écrit :
> Oh, thanx for your very informative answer. Ive added a link to your
> information in this thread:
>
> But... Sorry, but I wrote wrong. I meant "I will not recommend
> against HW raid + ZFS anymore" instead of "... recommend against HW
> raid
Le 4 janv. 09 à 21:09, milosz a écrit :
> thanks for your responses, guys...
>
> the nagle's tweak is the first thing i did, actually.
>
> not sure what the network limiting factors could be here... there's
> no switch, jumbo frames are on... maybe it's the e1000g driver?
> it's been wonky s
Try setting the cachemode property on the target filesystem.
Also verify that the source can pump data through the net at the
desired rate if the target is /dev/null.
-r
Le 8 janv. 09 à 18:46, gnomad a écrit :
> I have just built an opensolaris box (2008.11) as a small fileserver
> (6x 1TB
Le 9 déc. 08 à 03:16, Brent Jones a écrit :
> On Mon, Dec 8, 2008 at 3:09 PM, milosz wrote:
>> hi all,
>>
>> currently having trouble with sustained write performance with my
>> setup...
>>
>> ms server 2003/ms iscsi initiator 2.08 w/intel e1000g nic directly
>> connected to snv_101 w/ intel
Le 20 déc. 08 à 22:34, Dmitry Razguliaev a écrit :
> Hi, I faced with a similar problem, like Ross, but still have not
> found a solution. I have raidz out of 9 sata disks connected to
> internal and 2 external sata controllers. Bonnie++ gives me the
> following results:
> nexenta,8G,
> 10
HI Qihua, there are many reasons why the recordsize does not govern
the I/O size directly. Metadata I/O is one, ZFS I/O scheduler
aggregation is another.
The application behavior might be a third.
Make sure to create the DB files after modifying the ZFS property.
-r
Le 26 déc. 08 à 11:49, q
Le 15 déc. 08 à 01:13, Ahmed Kamal a écrit :
> Hi,
>
> I have been doing some basic performance tests, and I am getting a
> big hit when I run UFS over a zvol, instead of directly using zfs.
> Any hints or explanations is very welcome. Here's the scenario. The
> machine has 30G RAM, and two
Le 15 nov. 08 à 08:49, Nicholas Lee a écrit :
>
>
> On Sat, Nov 15, 2008 at 7:54 AM, Richard Elling <[EMAIL PROTECTED]
> > wrote:
> In short, separate logs with rotating rust may reduce sync write
> latency by
> perhaps 2-10x on an otherwise busy system. Using write optimized SSDs
> will redu
Le 22 oct. 08 à 21:02, Bill Sommerfeld a écrit :
> On Wed, 2008-10-22 at 09:46 -0700, Mika Borner wrote:
>> If I turn zfs compression on, does the recordsize influence the
>> compressratio in anyway?
>
> zfs conceptually chops the data into recordsize chunks, then
> compresses
> each chunk inde
Le 23 oct. 08 à 05:40, Constantin Gonzalez a écrit :
> Hi,
>
> Bob Friesenhahn wrote:
>> On Wed, 22 Oct 2008, Neil Perrin wrote:
>>> On 10/22/08 10:26, Constantin Gonzalez wrote:
3. Disable ZIL[1]. This is of course evil, but one customer
pointed out to me
that if a tar xvf we
Le 2 oct. 08 à 09:21, Christiaan Willemsen a écrit :
> Hi there.
>
> I just got a new Adaptec RAID 51645 controller in because the old
> (other type) was malfunctioning. It is paired with 16 Seagate 15k5
> disks, of which two are used with hardware RAID 1 for OpenSolaris
> snv_98, and the r
Leave the default recordsize. With 128K recordsize, files smaller than
128K are stored as single record
tightly fitted to the smallest possible # of disk sectors. Reads and
writes are then managed with fewer ops.
Not tuning the recordsize is very generally more space efficient and
more perf
Files are stored as either a single record (ajusted to the size of the
file) multiple number of fixed size records.
-r
Le 25 août 08 à 09:21, Robert a écrit :
> Thanks for your response, from which I have known more details.
> However, there is one thing I am still not clear--maybe at first
Le 28 juin 08 à 05:14, Robert Milkowski a écrit :
> Hello Mark,
>
> Tuesday, April 15, 2008, 8:32:32 PM, you wrote:
>
> MM> The new write throttle code put back into build 87 attempts to
> MM> smooth out the process. We now measure the amount of time it
> takes
> MM> to sync each transaction g
Le 30 mars 08 à 15:57, Kyle McDonald a écrit :
> Fred Oliver wrote:
>>
>> Marion Hakanson wrote:
>>> [EMAIL PROTECTED] said:
I am having trouble destroying a zfs file system (device busy) and
fuser
isn't telling me who has the file open: . . .
This situation appears to occur e
Le 3 mars 08 à 09:58, Robert Milkowski a écrit :
> Hello zfs-discuss,
>
>
> I had a zfs file system with recordsize=8k and a couple of large
> files. While doing zfs send | zfs recv I noticed it's doing
> about 1500 IOPS but with block size 8K so total throughput
> wasn't impr
Le 1 mars 08 à 22:14, Bill Shannon a écrit :
> Jonathan Edwards wrote:
>>
>> On Mar 1, 2008, at 3:41 AM, Bill Shannon wrote:
>>> Running just plain "iosnoop" shows accesses to lots of files, but
>>> none
>>> on my zfs disk. Using "iosnoop -d c1t1d0" or "iosnoop -m
>>> /export/home/shannon"
>>>
Le 28 févr. 08 à 21:00, Jonathan Loran a écrit :
>
>
> Roch Bourbonnais wrote:
>>
>> Le 28 févr. 08 à 20:14, Jonathan Loran a écrit :
>>
>>>
>>> Quick question:
>>>
>>> If I create a ZFS mirrored pool, will the read performance get
Le 28 févr. 08 à 20:14, Jonathan Loran a écrit :
>
> Quick question:
>
> If I create a ZFS mirrored pool, will the read performance get a
> boost?
> In other words, will the data/parity be read round robin between the
> disks, or do both mirrored sets of data and parity get read off of
> both
I would imagine that linux to behave more like ZFS that does not flush
caches.
(google Evil zfs_nocacheflush).
If you can nfs tar extract files on linux faster than one file per
rotation latency;
that is suspicious.
-r
Le 26 févr. 08 à 13:16, msl a écrit :
>> For Linux NFS service, it's a
Le 20 févr. 08 à 23:03, Robert Milkowski a écrit :
> Hello Roch,
>
> Friday, February 15, 2008, 10:51:50 AM, you wrote:
>
> RB> Le 10 févr. 08 à 12:51, Robert Milkowski a écrit :
>
>>> Hello Nathan,
>>>
>>> Thursday, February 7, 2008, 6:54:39 AM, you wrote:
>>>
>>> NK> For kicks, I disabled the Z
Le 15 févr. 08 à 18:24, Bob Friesenhahn a écrit :
> On Fri, 15 Feb 2008, Roch Bourbonnais wrote:
>>>
>>> As mentioned before, the write rate peaked at 200MB/second using
>>> RAID-0 across 12 disks exported as one big LUN.
>>
>> What was the interlace
Le 15 févr. 08 à 11:38, Philip Beevers a écrit :
> Hi everyone,
>
> This is my first post to zfs-discuss, so be gentle with me :-)
>
> I've been doing some testing with ZFS - in particular, in
> checkpointing
> the large, proprietary in-memory database which is a key part of the
> application I
Le 10 févr. 08 à 12:51, Robert Milkowski a écrit :
> Hello Nathan,
>
> Thursday, February 7, 2008, 6:54:39 AM, you wrote:
>
> NK> For kicks, I disabled the ZIL: zil_disable/W0t1, and that made
> not a
> NK> pinch of difference. :)
>
> Have you exported and them imported pool to get zil_disable
Le 15 févr. 08 à 03:34, Bob Friesenhahn a écrit :
> On Thu, 14 Feb 2008, Tim wrote:
>>
>> If you're going for best single file write performance, why are you
>> doing
>> mirrors of the LUNs? Perhaps I'm misunderstanding why you went
>> from one
>> giant raid-0 to what is essentially a raid-1
Le 14 févr. 08 à 02:22, Marion Hakanson a écrit :
> [EMAIL PROTECTED] said:
>> It's not that old. It's a Supermicro system with a 3ware 9650SE-8LP.
>> Open-E iSCSI-R3 DOM module. The system is plenty fast. I can pretty
>> handily pull 120MB/sec from it, and write at over 100MB/sec. It
>> f
No need to tune recordsize when the filesizes are small. Each file is
stored as a single record.
-r
Le 29 nov. 07 à 08:20, Kam Lane a écrit :
> I'm getting ready to test a thumper (500gig drives/ 16GB) as a
> backup store for small (avg 2kb) encrypted text files. I'm
> considering a zpool
Le 21 oct. 07 à 02:40, Vincent Fox a écrit :
> We had a Sun Engineer on-site recently who said this:
>
> We should set our array controllers to sequential I/O *even* if we
> are doing random I/O if we are using ZFS.
> This is because the Arc cache is already grouping requests up
> sequentiall
The theory I am going by is that 10 seconds worth of your synchronous
writes is sufficient
for the slog. That breaks down if the main pool is the bottleneck.
-r
Le 26 sept. 07 à 20:10, Torrey McMahon a écrit :
> Albert Chin wrote:
>> On Tue, Sep 25, 2007 at 06:01:00PM -0700, Vincent Fox wrot
Dedicate some CPU to the task. Create a psrset and bind the ftp
daemon to it.
If that works then add a few of the read threads as many as what fits
in the requirements.
-r
Le 25 juin 07 à 15:00, Paul van der Zwan a écrit :
On 25 Jun 2007, at 14:37, [EMAIL PROTECTED] wrote:
On 25 Ju
Le 20 juin 07 à 04:59, Ian Collins a écrit :
I'm not sure why, but when I was testing various configurations with
bonnie++, 3 pairs of mirrors did give about 3x the random read
performance of a 6 disk raidz, but with 4 pairs, the random read
performance dropped by 50%:
3x2
Blockread: 22
Le 29 mai 07 à 22:59, [EMAIL PROTECTED] a écrit :
When sequential I/O is done to the disk directly there is no
performance
degradation at all.
All filesystems impose some overhead compared to the rate of raw disk
I/O. It's going to be hard to store data on a disk unless some
kind of
fil
Le 22 mai 07 à 16:23, Dick Davies a écrit :
Take off every ZIL!
http://number9.hellooperator.net/articles/2007/02/12/zil-
communication
Cause client corrupt but also database corruption and just about
anything that carefully manages data.
Yes the zpool will survive, but it may be t
Le 22 mai 07 à 03:18, Frank Cusack a écrit :
On May 21, 2007 6:30:42 PM -0500 Nicolas Williams
<[EMAIL PROTECTED]> wrote:
On Mon, May 21, 2007 at 06:21:40PM -0500, Albert Chin wrote:
On Mon, May 21, 2007 at 06:11:36PM -0500, Nicolas Williams wrote:
> On Mon, May 21, 2007 at 06:09:46PM -0500,
Le 22 mai 07 à 01:21, Albert Chin a écrit :
On Mon, May 21, 2007 at 06:11:36PM -0500, Nicolas Williams wrote:
On Mon, May 21, 2007 at 06:09:46PM -0500, Albert Chin wrote:
But still, how is tar/SSH any more multi-threaded than tar/NFS?
It's not that it is, but that NFS sync semantics and ZFS
Le 22 mai 07 à 01:11, Nicolas Williams a écrit :
On Mon, May 21, 2007 at 06:09:46PM -0500, Albert Chin wrote:
But still, how is tar/SSH any more multi-threaded than tar/NFS?
It's not that it is, but that NFS sync semantics and ZFS sync
semantics
conspire against single-threaded performanc
hi Shweta;
First thing is to look for all kernel function return that errno (25
I think) during your test.
dtrace -n 'fbt:::return/arg1 == 25/[EMAIL PROTECTED]()}'
More verbose but also useful :
dtrace -n 'fbt:::return/arg1 == 25/[EMAIL PROTECTED](20)]=count()}'
It's a cat
This looks like another instance of
6429205 each zpool needs to monitor its throughput and throttle
heavy writers|
or at least it is a contributing factor.
Note that your /etc/system is mispelled (maybe just in the e-mail)
Didn't you get a console message ?
-r
Le 24 mai 07 à 09:50, Amer
with recent bits ZFS compression is now handled concurrently with
many CPUs working on different records.
So this load will burn more CPUs and acheive it's results
(compression) faster.
So the observed pauses should be consistent with that of a load
generating high system time.
The assump
Le 4 avr. 07 à 10:01, Paul Boven a écrit :
Hi everyone,
Swap would probably have to go on a zvol - would that be best
placed on
the n-way mirror, or on the raidz?
From the book of Richard Elling,
Shouldn't matter. The 'existence' of a swap device is sometimes
required.
If the devic
Now, given proper I/O concurrency (like recently improved NCQ in our
drivers) or SCSI CTQ,
I don't not expect the write caches to provide much performance
gains, if any, over the situation
with write caches off.
Write caches can be extremelly effective when dealing with drives
that do not
Le 5 avr. 07 à 08:28, Robert Milkowski a écrit :
Hello Matthew,
Thursday, April 5, 2007, 1:08:25 AM, you wrote:
MA> Lori Alt wrote:
Can write-cache not be turned on manually as the user is sure
that it is
only ZFS that is using the entire disk?
yes it can be turned on. But I don't know
Le 30 mars 07 à 20:32, Anton Rang a écrit :
Perhaps you should read the QFS documentation and/or source. :-)
I probably should...
QFS, like
other write-forward and/or delayed-allocation file systems, does
not incur a
seek per I/O. For sequential writes in a typical data capture
applic
Le 30 mars 07 à 08:36, Anton B. Rang a écrit :
However, even with sequential writes, a large I/O size makes a huge
difference in throughput. Ask the QFS folks about data capture
applications. ;-)
I quantified the 'huge' this as such
60MB/s and 5ms per seek means that for a FS that requ
Any details on the use case ?
Such an option will clearly make any filesystem just crawl on so many
common operation.
So it's rather interesting to know who/what is ready to sacrifice so
much performance.
In exchange for what ?
Le 8 mars 07 à 21:19, Bruce Shaw a écrit :
Would a forcesyn
Le 8 mars 07 à 20:08, Selim Daoud a écrit :
robert,
this applies only if you have full control on the application forsure
..but how do you do it if you don't own the application ... can you
mount zfs with forcedirectio flag ?
selim
ufs directio and O_DSYNC are different things.
Would a forc
Le 26 févr. 07 à 18:30, Frank Cusack a écrit :
On February 26, 2007 9:05:21 AM -0800 Jeff Davis
<[EMAIL PROTECTED]> wrote:
That got me worried about the project I'm working on, and I wanted to
understand ZFS's caching behavior better to prove to myself that the
problem wouldn't happen under Z
DIRECT IO is a set of performance optimisations to circumvent
shortcomings of a given filesystem.
Check out
http://blogs.sun.com/roch/entry/zfs_and_directio
Then I would be interested to know what is the expectation for ZFS/DIO.
Le 5 janv. 07 à 06:39, dudekula mastan a écrit :
Hi
It seems though that the critical feature we need was optional in the
SBC-2 spec.
So we still need some development to happen on the storage end.
But we'll get there...
Le 19 déc. 06 à 20:59, Jason J. W. Williams a écrit :
Hi Roch,
That sounds like a most excellent resolution to me. :-)
I've discussed this with some guys I know, and we decided that your
admin must have given you an incorrect description.
BTW, that config falls outside of best practice; The current thinking
is to use raid-z group of not much more than 10 disks.
You may stripe multiple such groups into a pool
I'm puzzled by 2 things.
Naively I'd think a write_cache should not help throughput
test since the cache should fill up after which you should still be
throttled by the physical drain rate. You clearly show that
it helps; Anyone knows why/how a cache helps throughput ?
And the second thing...q
Tao Chen writes:
> Hello Robert,
>
> On 6/1/06, Robert Milkowski <[EMAIL PROTECTED]> wrote:
> > Hello Anton,
> >
> > Thursday, June 1, 2006, 5:27:24 PM, you wrote:
> >
> > ABR> What about small random writes? Won't those also require reading
> > ABR> from all disks in RAID-Z to read the
You propose ((2-way mirrored) x RAID-Z (3+1)) . That gives
you 3 data disks worth and you'd have to loose 2 disk in
each mirror (4 total) to loose data.
For random read load you describe, I could expect that the
per device cache to work nicely; That is file blocks stored
at some given
Robert Milkowski writes:
>
>
>
> btw: just a quick thought - why not to write one block only on 2 disks
> (+checksum on a one disk) instead of spreading one fs block to N-1
> disks? That way zfs could read many fs block at the same time in case
> of larger raid-z pools. ?
That's what y
> I think ZFS should do fine in streaming mode also, though there are
> currently some shortcomings, such as the mentioned 128K I/O size.
It may eventually. The lack of direct I/O may also be an issue, since
some of our systems don't have enough main memory bandwidth to support
data be
Anton wrote:
(For what it's worth, the current 128K-per-I/O policy of ZFS really
hurts its performance for large writes. I imagine this would not be
too difficult to fix if we allowed multiple 128K blocks to be
allocated as a group.)
I'm not taking a stance on this, but if I keep a co
Hi Grant, this may provide some guidance for your setup;
it's somewhat theoretical (take it for what it's worth) but
it spells out some of the tradeoffs in the RAID-Z vs Mirror
battle:
http://blogs.sun.com/roller/page/roch?entry=when_to_and_not_to
As for serving NFS, the user e
Chris Csanady writes:
> On 5/26/06, Bart Smaalders <[EMAIL PROTECTED]> wrote:
> >
> > There are two failure modes associated with disk write caches:
>
> Failure modes aside, is there any benefit to a write cache when command
> queueing is available? It seems that the primary advantage is i
Scott Dickson writes:
> How does (or does) ZFS maintain sequentiality of the blocks of a file.
> If I mkfile on a clean UFS, I likely will get contiguous blocks for my
> file, right? A customer I talked to recently has a desire to access
you would get up to maxcontig worth of sequential b
Cool, I'll try the tool and for good measure the data I
posted was sequential access (from logical point of view).
As for the physical layout, Idon't know, it's quite
possible that ZFS has layed out all blocks sequentially on
the physical side; so certainly this is not a good way
Gregory Shaw writes:
> Rich, correct me if I'm wrong, but here's the scenario I was thinking
> of:
>
> - A large file is created.
> - Over time, the file grows and shrinks.
>
> The anticipated layout on disk due to this is that extents are
> allocated as the file changes. The extent
disk block will be.
So everything is a tradeoff and at this point 128K appears
sufficiently large ... at least for a while.
-r
________
Roch BourbonnaisSun Microsystems, Icnc-Grenoble
Se
Robert Milkowski writes:
> Hello Roch,
>
> Monday, May 15, 2006, 3:23:14 PM, you wrote:
>
> RBPE> The question put forth is whether the ZFS 128K blocksize is sufficient
> RBPE> to saturate a regular disk. There is great body of evidence that shows
> RBPE> that the bigger the write sizes a
Anton B. Rang writes:
> One issue is what we mean by "saturation." It's easy to
bring a disk to 100% busy. We need to keep this discussion
in the context of a workload. Generally when people care
about streaming throghput of a disk, it's because they are
reading or writing a single large file
Gregory Shaw writes:
> I really like the below idea:
> - the ability to defragment a file 'live'.
>
> I can see instances where that could be very useful. For instance,
> if you have multiple LUNs (or spindles, whatever) using ZFS, you
> could re-optimize large files to spre
The question put forth is whether the ZFS 128K blocksize is sufficient
to saturate a regular disk. There is great body of evidence that shows
that the bigger the write sizes and matching large FS clustersize lead
to more throughput. The counter point is that ZFS schedules it's I/O
like nothing
Nicolas Williams writes:
> On Fri, May 12, 2006 at 05:23:53PM +0200, Roch Bourbonnais - Performance
> Engineering wrote:
> > For read it is an interesting concept. Since
> >
> >Reading into cache
> >Then copy into user space
> >th
Robert Milkowski writes:
> Hello Roch,
>
> Friday, May 12, 2006, 2:28:59 PM, you wrote:
>
> RBPE> Hi Robert,
>
> RBPE> Could you try 35 concurrent dd each issuing 128K I/O ?
> RBPE> That would be closer to how ZFS would behave.
>
> You mean to UFS?
>
> ok, I did try and I get about
Anton B. Rang writes:
> >Were the benefits coming from extra concurrency (no
> >single writer lock) or avoiding the extra copy to page cache or
> >from too much readahead that is not used before pages need to
> >be recycled.
>
> With QFS, a major benefit we see for databases and direct I/
Franz Haberhauer writes:
> > 'ZFS optimizes random writes versus potential sequential reads.'
>
> This remark focused on the allocation policy during writes,
> not the readahead that occurs during reads.
> Data that are rewritten randomly but in place in a sequential,
> contiguos file (l
1 - 100 of 114 matches
Mail list logo
