Ok, build 117 does seem a lot better. The second run is slower, but not by
such a huge margin. This was the end of the 98GB test:
Creating data file set (12000 files of 8192000 bytes) under /rpool/zfscachetest
...
Done!
zfs unmount rpool/zfscachetest
zfs mount rpool/zfscachetest
Doing initial
last question! I promise :)
Google's not helped me much, but that's probably my keyword-ignorance.
I have two USB HDD's, I want to swap them over, so there's one off-site and one
plugged in, they get swapped over weekly. Not perfect, but sufficient for this
site's risk assessment. They'll have
Bob: Sun v490, 4x1.35 processors, 32GB ram, Solaris 10u7 working with a raidz1
zpool made up of 6x146 sas drives on a j4200. Results of your running your
script:
# zfs-cache-test.ksh pool2
zfs create pool2/zfscachetest
Creating data file set (6000 files of 8192000 bytes) under /pool2/zfscachete
On Mon, 13 Jul 2009, Joerg Schilling wrote:
If you continue to use cpio and the cpio archive format, you force copying a
lot of data as the cpio archive format does use odd header sizes and starts
new files "unaligned" directly after the archive header.
Note that the output of cpio is sent to
On Mon, 13 Jul 2009, Mark Shellenbaum wrote:
I've opened the following bug to track this issue:
6859997 zfs caching performance problem
We need to track down if/when this problem was introduced or if it
has always been there.
I think that it has always been there as long as I have been usin
On Mon, Jul 13, 2009 at 4:41 PM, Bob
Friesenhahn wrote:
> On Mon, 13 Jul 2009, Jim Mauro wrote:
>
>> Bob - Have you filed a bug on this issue? I am not up to speed on this
>> thread, so I can not comment on whether or not there is a bug here, but you
>> seem to have a test case and supporting data.
On Mon, 13 Jul 2009, Jim Mauro wrote:
Bob - Have you filed a bug on this issue? I am not up to speed on
this thread, so I can not comment on whether or not there is a bug
here, but you seem to have a test case and supporting data. Filing a
bug will get the attention of ZFS engineering.
No, I
Bob Friesenhahn wrote:
> On Mon, 13 Jul 2009, Mike Gerdts wrote:
> >
> > Using cpio's -C option seems to not change the behavior for this bug,
> > but I did see a performance difference with the case where I hadn't
> > modified the zfs caching behavior. That is, the performance of the
> > tmpfs
Mike Gerdts wrote:
> Using cpio's -C option seems to not change the behavior for this bug,
> but I did see a performance difference with the case where I hadn't
> modified the zfs caching behavior. That is, the performance of the
> tmpfs backed vdisk more than doubled with "cpio -o -C $((1024 *
Bob Friesenhahn wrote:
> On Mon, 13 Jul 2009, Joerg Schilling wrote:
> >
> > cpio reads/writes in 8192 byte chunks from the filesystem.
>
> Yes, I was just reading the cpio manual page and see that. I think
> that re-reading the 128K zfs block 16 times to satisfy each request
> for 8192 bytes
Bob Friesenhahn wrote:
There has been no forward progress on the ZFS read performance issue for
a week now. A 4X reduction in file read performance due to having read
the file before is terrible, and of course the situation is considerably
worse if the file was previously mmapped as well. Man
On Mon, 13 Jul 2009, Ross Walker wrote:
Have you tried limiting the ARC so it doesn't squash the page cache?
Yes, the ARC is limited to 10GB, leaving another 10GB for the OS and
applications. Resource limits are not the problem. There is a ton of
memory and CPU to go around.
Current /etc
On Mon, 13 Jul 2009, Mike Gerdts wrote:
Using cpio's -C option seems to not change the behavior for this bug,
but I did see a performance difference with the case where I hadn't
modified the zfs caching behavior. That is, the performance of the
tmpfs backed vdisk more than doubled with "cpio -o
On Jul 13, 2009, at 2:54 PM, Bob Friesenhahn > wrote:
On Mon, 13 Jul 2009, Brad Diggs wrote:
You might want to have a look at my blog on filesystem cache
tuning... It will probably help
you to avoid memory contention between the ARC and your apps.
http://www.thezonemanager.com/2009/03/file
On Mon, Jul 13, 2009 at 3:23 PM, Bob
Friesenhahn wrote:
> On Mon, 13 Jul 2009, Joerg Schilling wrote:
>>
>> cpio reads/writes in 8192 byte chunks from the filesystem.
>
> Yes, I was just reading the cpio manual page and see that. I think that
> re-reading the 128K zfs block 16 times to satisfy eac
On Mon, Jul 13, 2009 at 3:16 PM, Joerg
Schilling wrote:
> Bob Friesenhahn wrote:
>
>> On Mon, 13 Jul 2009, Mike Gerdts wrote:
>> >
>> > FWIW, I hit another bug if I turn off primarycache.
>> >
>> > http://defect.opensolaris.org/bz/show_bug.cgi?id=10004
>> >
>> > This causes really abysmal performa
On Mon, 13 Jul 2009, Joerg Schilling wrote:
cpio reads/writes in 8192 byte chunks from the filesystem.
Yes, I was just reading the cpio manual page and see that. I think
that re-reading the 128K zfs block 16 times to satisfy each request
for 8192 bytes explains the 16X performance loss when
> "jcm" == James C McPherson writes:
> "dm" == David Magda writes:
jcm> What I can say, however, is that "open source" does not always
jcm> equate to requiring "open development".
+1
To maintain what draws me to free software, you must
* release binaries and source at the same
Bob - Have you filed a bug on this issue?
I am not up to speed on this thread, so I can
not comment on whether or not there is a bug
here, but you seem to have a test case and supporting
data. Filing a bug will get the attention of ZFS
engineering.
Thanks,
/jim
Bob Friesenhahn wrote:
On Mon, 1
Bob Friesenhahn wrote:
> On Mon, 13 Jul 2009, Mike Gerdts wrote:
> >
> > FWIW, I hit another bug if I turn off primarycache.
> >
> > http://defect.opensolaris.org/bz/show_bug.cgi?id=10004
> >
> > This causes really abysmal performance - but equally so for repeat runs!
>
> It is quite facinating s
On Mon, 13 Jul 2009, Mike Gerdts wrote:
FWIW, I hit another bug if I turn off primarycache.
http://defect.opensolaris.org/bz/show_bug.cgi?id=10004
This causes really abysmal performance - but equally so for repeat runs!
It is quite facinating seeing the huge difference in I/O performance
fr
Something caused my original message to get cut off. Here is the full post:
1) Turning on write caching is potentially dangerous because the disk will
indicate that data has been written (to cache) before it has actually been
written to non-volatile storage (disk). Since the factory has no way o
1) Turning on write caching is potentially dangerous because the disk will
indicate that data has been written (to cache) before it has actually been
written to non-volatile storage (disk). Since the factory has no way of knowing
how you'll use your T5140, I'm guessing that they set the disk wri
On Mon, Jul 13, 2009 at 9:34 AM, Bob
Friesenhahn wrote:
> On Mon, 13 Jul 2009, Alexander Skwar wrote:
>>
>> Still on S10 U7 Sparc M4000.
>>
>> So I'm now inline with the other results - the 2nd run is WAY slower. 4x
>> as slow.
>
> It would be good to see results from a few OpenSolaris users runnin
Sun X4500 (thumper) with 16Gb of memory running Solaris 10 U6 with patches
current to the end of Feb 2009.
Current ARC size is ~6Gb.
ZFS filesystem created in a ~3.2 Tb pool consisting of 7 sets of mirrored 500Gb
SATA drives.
I used 4000 8Mb files for a total of 32Gb.
run 1: ~140M/s average a
On Mon, 13 Jul 2009, Brad Diggs wrote:
You might want to have a look at my blog on filesystem cache tuning... It
will probably help
you to avoid memory contention between the ARC and your apps.
http://www.thezonemanager.com/2009/03/filesystem-cache-optimization.html
Your post makes it sound
joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) writes:
> Harry Putnam wrote:
>
>> Dennis Clarke writes:
>>
>> > This will probably get me bombed with napalm but I often just
>> > use star from Jörg Schilling because its dead easy :
>> >
>> > star -copy -p -acl -sparse -dump -C old_dir .
On 07/11/09 05:15, iman habibi wrote:
Dear Admins
I had solaris 10u8 installation based on ZFS (rpool)filesystem on two
mirrored scsi disks in sunfire v880.
but after some months,when i reboot server with reboot command,it
didnt boot from disks,and returns cant boot from boot media.
how can i
You might want to have a look at my blog on filesystem cache
tuning... It will probably help
you to avoid memory contention between the ARC and your apps.
http://www.thezonemanager.com/2009/03/filesystem-cache-optimization.html
Brad
Brad Diggs
Senior Directory Architect
Virtualization
Joerg Schilling wrote:
Darren J Moffat wrote:
use star from Jörg Schilling because its dead easy :
star -copy -p -acl -sparse -dump -C old_dir . new_dir
...
star doesn't (and shouldn't) create the destination ZFS filesystem like
the zfs recv would. It also doesn't preserve the dataset l
Interesting, I repeated the test on a few other machines running newer builds.
First impressions are good:
snv_114, virtual machine, 1GB RAM, 30GB disk - 16% slowdown.
(Only 9GB free so I ran an 8GB test)
Doing initial (unmount/mount) 'cpio -o > /dev/null'
1683 blocks
real3m4.85s
user
Darren J Moffat wrote:
> >>> use star from Jörg Schilling because its dead easy :
> >>>
> >>> star -copy -p -acl -sparse -dump -C old_dir . new_dir
...
> star doesn't (and shouldn't) create the destination ZFS filesystem like
> the zfs recv would. It also doesn't preserve the dataset level w
On Jul 13, 2009, at 11:33 AM, Ross wrote:
Gaaah, looks like I spoke too soon:
$ zpool status
pool: rc-pool
state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
An
attempt was made to correct the error. Applications are
unaffected.
action: Determine
Ross,
The disks do have problems - that's why I'm resilvering.
I've seen zero read, write or checksum errors and had it loop. Now I
do have a number of read errors on some of the disks, but I think
resilvering is missing the point if it can't deal with corrupt data or
disks with a small am
Gaaah, looks like I spoke too soon:
$ zpool status
pool: rc-pool
state: DEGRADED
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear t
Joerg Schilling wrote:
Harry Putnam wrote:
Dennis Clarke writes:
This will probably get me bombed with napalm but I often just
use star from Jörg Schilling because its dead easy :
star -copy -p -acl -sparse -dump -C old_dir . new_dir
and you're done.[1]
So long as you have both the new
Harry Putnam wrote:
> Dennis Clarke writes:
>
> > This will probably get me bombed with napalm but I often just
> > use star from Jörg Schilling because its dead easy :
> >
> > star -copy -p -acl -sparse -dump -C old_dir . new_dir
> >
> > and you're done.[1]
> >
> > So long as you have both th
No, I don't think I need to take a disk out. It's running ok now, it just
seemed to get a bit confused at the start:
$ zpool status
pool: rc-pool
state: DEGRADED
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Application
Hello experts,
I would like consult you some questions regarding RFE 6334757
and CR 6322205 (disk write cache).
==
RFE 6334757
disk write cache should be enabled and should have a tool to
switch it on and off
CR 6322205
Enable disk write cache if ZFS owns
On Mon, 13 Jul 2009, Alexander Skwar wrote:
Still on S10 U7 Sparc M4000.
So I'm now inline with the other results - the 2nd run is WAY slower. 4x
as slow.
It would be good to see results from a few OpenSolaris users running a
recent 64-bit kernel, and with fast storage to see if this is an
> Dennis Clarke writes:
>
>> This will probably get me bombed with napalm but I often just
>> use star from Jörg Schilling because its dead easy :
>>
>> star -copy -p -acl -sparse -dump -C old_dir . new_dir
>>
>> and you're done.[1]
>>
>> So long as you have both the new and the old zfs/ufs/wh
Dennis Clarke writes:
> This will probably get me bombed with napalm but I often just
> use star from Jörg Schilling because its dead easy :
>
> star -copy -p -acl -sparse -dump -C old_dir . new_dir
>
> and you're done.[1]
>
> So long as you have both the new and the old zfs/ufs/whatever[2]
> f
On Mon, 13 Jul 2009, Alexander Skwar wrote:
This is a M4000 mit 32 GB RAM and two HDs in a mirror.
I think that you should edit the script to increase the file count
since your RAM size is big enough to cache most of the data.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.
Maybe it's the disks firmware that is bad or maybe they're jumpered
for 1.5Gbps on a 3.0 only bus? Or maybe it's a problem with the disk
cable/bay/enclosure/slot?
It sounds like there is more then ZFS in the mix here. I wonder if the
drive's status keeps flapping online/offline and either
Ross,
I feel you here, but I don't have much of a solution.
The best I can suggest (and has been my solution) is to take out the
problematic disk, copy it to a fresh disk (preferably using something
like dd_rescue) and then re-install.
It seems the resilvering loop is generally a result of
Thanks to the help of a zfs/kernel developer at Sun who volunteered to help me,
it turns out this was a bug in solaris that needs to be fixed. Bug report here
for the curious:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6859446
--
This message posted from opensolaris.org
__
> Richard Elling writes:
>
>> You can only send/receive snapshots. However, on the receiving end,
>> there will also be a dataset of the name you choose. Since you didn't
>> share what commands you used, it is pretty impossible for us to
>> speculate what you might have tried.
>
> I thought I m
Here's a more useful output, with having set the number of
files to 6000, so that it has a dataset which is larger than the
amount of RAM.
--($ ~)-- time sudo ksh zfs-cache-test.ksh
zfs create rpool/zfscachetest
Creating data file set (6000 files of 8192000 bytes) under
/rpool/zfscachetest ...
Don
Ross Walker writes:
> Once the data is copied you can delete the snapshots that will then
> exist on both pools.
That's the part right there that wasn't apparent.
That
zfs send z1/someth...@snap |zfs receive z2/someth...@snap
Would also create z2/something
> If you have mount options set u
Richard Elling writes:
> You can only send/receive snapshots. However, on the receiving end,
> there will also be a dataset of the name you choose. Since you didn't
> share what commands you used, it is pretty impossible for us to
> speculate what you might have tried.
I thought I made it clea
Just look at this. I thought all the restarting resilver bugs were fixed, but
it looks like something odd is still happening at the start:
Status immediately after starting resilver:
# zpool status
pool: rc-pool
state: DEGRADED
status: One or more devices has experienced an unrecoverable err
x4540 running svn117
# ./zfs-cache-test.ksh zpool1
zfs create zpool1/zfscachetest
creating data file set 93000 files of 8192000 bytes0 under
/zpool1/zfscachetest ...
done1
zfs unmount zpool1/zfscachetest
zfs mount zpool1/zfscachetest
doing initial (unmount/mount) 'cpio -o . /dev/null'
4800024
Yup, just hit exactly the same myself. I have a feeling this faulted disk is
affecting performance, so tried to remove or offline it:
$ zpool iostat -v 30
capacity operationsbandwidth
pool used avail read write read write
-- - - - --
Hi,
Solaris 10U7, patched to the latest released patches two weeks ago.
Four ST31000340NS attached to two SI3132 SATA controller, RAIDZ1.
Selfmade system with 2GB RAM and an
x86 (chipid 0x0 AuthenticAMD family 15 model 35 step 2 clock 2210 MHz)
AMD Athlon(tm) 64 X2 Dual Core Processo
Hey Bob,
Here are my results on a Dual 2.2Ghz Opteron, 8GB of RAM and 16 SATA disks
connected via a Supermicro AOC-SAT2-MV8 (albeit with one dead drive).
Looks like a 5x slowdown to me:
Doing initial (unmount/mount) 'cpio -o > /dev/null'
48000247 blocks
real4m46.45s
user0m10.29s
sys
Bob,
On Sun, Jul 12, 2009 at 23:38, Bob
Friesenhahn wrote:
> There has been no forward progress on the ZFS read performance issue for a
> week now. A 4X reduction in file read performance due to having read the
> file before is terrible, and of course the situation is considerably worse
> if the
Richard,
> Also, we now know the market value for dedupe intellectual property: $2.1
> Billion.
> Even though there may be open source, that does not mean there are not IP
> barriers. $2.1 Billion attracts a lot of lawyers :-(
Indeed, good point.
--
Regards,
Cyril
_
Hi,
Here is the result on a Dell Precision T5500 with 24 GB of RAM and two
HD in a mirror (SATA, 7200 rpm, NCQ).
[glehm...@marvin2 tmp]$ uname -a
SunOS marvin2 5.11 snv_117 i86pc i386 i86pc Solaris
[glehm...@marvin2 tmp]$ pfexec ./zfs-cache-test.ksh
zfs create rpool/zfscachetest
Creating dat
58 matches
Mail list logo
