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
Hmmm, so there is lots of evictable cache here (mostly in the MFU
part of the cache)... could you make your core file available?
I would like to take a look at it.
Isn't this just like:
6493923 nfsfind on ZFS filesystem quickly depletes memory in a 1GB system
Which was introduced in
Hello Tomas,
Friday, January 5, 2007, 4:00:53 AM, you wrote:
TÖ On 04 January, 2007 - Tomas Ögren sent me these 1,0K bytes:
On 03 January, 2007 - [EMAIL PROTECTED] sent me these 0,5K bytes:
Hmmm, so there is lots of evictable cache here (mostly in the MFU
part of the cache)... could
On 05 January, 2007 - Robert Milkowski sent me these 3,8K bytes:
Hello Tomas,
I saw the same behavior here when ncsize was increased from default.
Try with default and lets see what will happen - if it works then it's
better than hung every an hour or so.
That's still not the point.. It
I know there's been much discussion on the list lately about getting HW
arrays to use (or not use) their caches in a way that helps ZFS the most.
Just yesterday I started seeing articles on NAND Flash Drives, and I
know other Solid Stae Drive technologies have been around for a while
and many
I'm currently working on putting the ZFS intent log on separate devices
which could include seperate disks and nvram/solid state devices.
This would help any application using fsync/O_DSYNC - in particular
DB and NFS. From protoyping considerable peformanace improvements have
been seen.
Neil.
Ah, that's a major misconception on my part then. I'd thought I'd read
that unlike any other RAID implementation, ZFS checked and verified
parity on normal data access.
That would be useless, and not provide anything extra.
I think it's useless if a (disk) block of data holding RAIDZ
DIRECT IO is a set of performance optimisations to circumvent shortcomings of
a given filesystem.
Direct I/O as generally understood (i.e. not UFS-specific) is an optimization
which allows data to be transferred directly between user data buffers and
disk, without a memory-to-memory copy.
If [SSD or Flash] devices become more prevalent, and/or cheaper I'm curious
what
ways ZFS could be made to bast take advantage of them?
The intent log is a possibility, but this would work better with SSD than
Flash; Flash writes can actually be slower than sequential writes to a real
disk.
Thomas,
This could be fragmentation in the meta-data caches. Could you
print out the results of ::kmastat?
-Mark
Tomas Ögren wrote:
On 05 January, 2007 - Robert Milkowski sent me these 3,8K bytes:
Hello Tomas,
I saw the same behavior here when ncsize was increased from default.
Try with
On 05 January, 2007 - Mark Maybee sent me these 0,8K bytes:
Thomas,
This could be fragmentation in the meta-data caches. Could you
print out the results of ::kmastat?
http://www.acc.umu.se/~stric/tmp/zfs-dumps.tar.bz2
memstat, kmastat and dnlc_nentries from 10 minutes after boot up until
I have a pool of 48 500GB disks across four SCSI channels (12 per channel).
One of the disks failed, and was replaced. The pool is now in a degraded
state, but I can't seem to get the pool to be happy with the replacement. I
did a resilver and the pool is error free with the exception of
On Fri, Jan 05, 2007 at 10:14:21AM -0800, Eric Hill wrote:
I have a pool of 48 500GB disks across four SCSI channels (12 per
channel). One of the disks failed, and was replaced. The pool is now
in a degraded state, but I can't seem to get the pool to be happy with
the replacement. I did a
Hello Neil,
Friday, January 5, 2007, 4:36:05 PM, you wrote:
NP I'm currently working on putting the ZFS intent log on separate devices
NP which could include seperate disks and nvram/solid state devices.
NP This would help any application using fsync/O_DSYNC - in particular
NP DB and NFS. From
On Fri, 5 Jan 2007, Anton B. Rang wrote:
If [SSD or Flash] devices become more prevalent, and/or cheaper I'm curious
what
ways ZFS could be made to bast take advantage of them?
The intent log is a possibility, but this would work better with SSD than
Flash; Flash writes can actually be
Robert Milkowski wrote On 01/05/07 11:45,:
Hello Neil,
Friday, January 5, 2007, 4:36:05 PM, you wrote:
NP I'm currently working on putting the ZFS intent log on separate devices
NP which could include seperate disks and nvram/solid state devices.
NP This would help any application using
So it looks like this data does not include ::kmastat info from *after*
you reset arc_reduce_dnlc_percent. Can I get that?
What I suspect is happening:
1 with your large ncsize, you eventually ran the machine out
of memory because (currently) the arc is not accounting for
On 05 January, 2007 - Mark Maybee sent me these 1,5K bytes:
So it looks like this data does not include ::kmastat info from *after*
you reset arc_reduce_dnlc_percent. Can I get that?
Yeah, attached. (although about 18 hours after the others)
What I suspect is happening:
1 with your
Could this ability (separate ZIL device) coupled with an SSD give
something like a Thumper the write latency benefit of battery-backed
write cache?
Best Regards,
Jason
On 1/5/07, Neil Perrin [EMAIL PROTECTED] wrote:
Robert Milkowski wrote On 01/05/07 11:45,:
Hello Neil,
Friday, January 5,
Hi Bill,
vault:/#zpool replace pool c5t6d0
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c5t6d0s0 is part of active ZFS pool pool. Please see zpool(1M).
vault:/#zpool replace -f pool c5t6d0
invalid vdev specification
the following errors must be manually repaired:
On Jan 5, 2007, at 11:10, Anton B. Rang wrote:
DIRECT IO is a set of performance optimisations to circumvent
shortcomings of a given filesystem.
Direct I/O as generally understood (i.e. not UFS-specific) is an
optimization which allows data to be transferred directly between
user data
And to add more fuel to the fire, an fmdump -eV shows the following:
Jan 05 2007 11:30:38.030057310 ereport.fs.zfs.vdev.open_failed
nvlist version: 0
class = ereport.fs.zfs.vdev.open_failed
ena = 0x88c01b571200801
detector = (embedded nvlist)
nvlist version: 0
Tomas Ögren wrote:
On 05 January, 2007 - Mark Maybee sent me these 1,5K bytes:
So it looks like this data does not include ::kmastat info from *after*
you reset arc_reduce_dnlc_percent. Can I get that?
Yeah, attached. (although about 18 hours after the others)
Excellent, this confirms #3
On 05 January, 2007 - Tomas Ögren sent me these 33K bytes:
On 05 January, 2007 - Mark Maybee sent me these 1,5K bytes:
So it looks like this data does not include ::kmastat info from *after*
you reset arc_reduce_dnlc_percent. Can I get that?
Yeah, attached. (although about 18 hours
On 05 January, 2007 - Mark Maybee sent me these 2,9K bytes:
Tomas Ögren wrote:
On 05 January, 2007 - Mark Maybee sent me these 1,5K bytes:
So it looks like this data does not include ::kmastat info from *after*
you reset arc_reduce_dnlc_percent. Can I get that?
Yeah, attached. (although
Ok, now I'm getting somewhere.
vault:/#dd if=/dev/zero of=/dev/dsk/c5t6d0 bs=512 count=64000
64000+0 records in
64000+0 records out
vault:/#dd if=/dev/zero of=/dev/dsk/c5t6d0 bs=512 count=64000 oseek=976174591
64000+0 records in
64000+0 records out
vault:/#zpool replace pool c5t6d0
vault:/#
Hello Chris,
Wednesday, December 13, 2006, 12:25:40 PM, you wrote:
CG Robert Milkowski wrote:
Hello Chris,
Wednesday, December 6, 2006, 6:23:48 PM, you wrote:
CG One of our file servers internally to Sun that reproduces this
CG running nv53 here is the dtrace output:
Any conclusions
... If the block checksums
show OK, then reading the parity for the corresponding data yields no
additional useful information.
It would yield useful information about the status of the parity
information on disk.
The read would be done because you're already paying the penalty for
reading all
... If the block checksums
show OK, then reading the parity for the corresponding data yields no
additional useful information.
It would yield useful information about the status of the parity
information on disk.
The read would be done because you're already paying the penalty for
Al Hopper wrote:
On Fri, 5 Jan 2007, Anton B. Rang wrote:
If [SSD or Flash] devices become more prevalent, and/or cheaper I'm curious what
ways ZFS could be made to bast take advantage of them?
The intent log is a possibility, but this would work better with SSD than
Flash; Flash
It's not about the checksum but about how a fs block is stored in
raid-z[12] case - it's spread out to all non-parity disks so in order
to read one fs block you have to read from all disks except parity
disks.
However, if we didn't need to verify the checksum, we wouldn't
have to read the
Matthew Ahrens wrote:
Robert Milkowski wrote:
Hello zfs-discuss,
zfs recv -v at the end reported:
received 928Mb stream in 6346 seconds (150Kb/sec)
I'm not sure but shouldn't it be 928MB and 150KB ?
Or perhaps we're counting bits?
That's correct, it is in bytes and should use capital B.
Darren Dunham wrote:
That would be useless, and not provide anything extra.
I think it's useless if a (disk) block of data holding RAIDZ parity
never has silent corruption, or if scrubbing was a lightweight operation
that could be run often.
The problem is that you will still need to
Peter Schuller wrote:
I've been using a simple model for small, random reads. In that model,
the performance of a raidz[12] set will be approximately equal to a single
disk. For example, if you have 6 disks, then the performance for the
6-disk raidz2 set will be normalized to 1, and the
Summary (1.8 form factor): write: 35MB/Sec, Read: 62MB/Sec IOPS: 7,000
That is on par with a 5400 rpm disk, except for the 100x more small, random
read iops. The biggest issue is the pricing, which will become interestingly
competitive for mortals this year.
$600+ for a 32 GB device
35 matches
Mail list logo
