bash-3.00# dtrace -n fbt::txg_quiesce:return'{printf(%Y ,walltimestamp);}'
dtrace: description 'fbt::txg_quiesce:return' matched 1 probe
CPU IDFUNCTION:NAME
3 38168 txg_quiesce:return 2007 Feb 12 14:08:15
0 38168 txg_quiesce:return 2007
Robert Milkowski writes:
bash-3.00# dtrace -n fbt::txg_quiesce:return'{printf(%Y ,walltimestamp);}'
dtrace: description 'fbt::txg_quiesce:return' matched 1 probe
CPU IDFUNCTION:NAME
3 38168 txg_quiesce:return 2007 Feb 12 14:08:15
0 38168
Hello Roch,
Monday, February 12, 2007, 3:19:23 PM, you wrote:
RP Robert Milkowski writes:
bash-3.00# dtrace -n fbt::txg_quiesce:return'{printf(%Y ,walltimestamp);}'
dtrace: description 'fbt::txg_quiesce:return' matched 1 probe
CPU IDFUNCTION:NAME
3 38168
Duh!.
Long sync (which delays the next sync) are also possible on
a write intensive workloads. Throttling heavy writters, I
think, is the key to fixing this.
Robert Milkowski writes:
Hello Roch,
Monday, February 12, 2007, 3:19:23 PM, you wrote:
RP Robert Milkowski writes:
Hello Matty,
Monday, February 12, 2007, 1:44:13 AM, you wrote:
M On 2/11/07, Robert Milkowski [EMAIL PROTECTED] wrote:
Hello Matty,
Sunday, February 11, 2007, 6:56:14 PM, you wrote:
M Howdy,
M On one of my Solaris 10 11/06 servers, I am getting numerous errors
M similar to the following:
I had the same issue with zfs killing my Ultra20. I can confirm that flashing
the BIOS fixed the issue.
http://www.sun.com/desktop/workstation/ultra20/downloads.jsp#Ultra
Eric
This message posted from opensolaris.org
___
zfs-discuss mailing list
Hello Roch,
Monday, February 12, 2007, 3:54:30 PM, you wrote:
RP Duh!.
RP Long sync (which delays the next sync) are also possible on
RP a write intensive workloads. Throttling heavy writters, I
RP think, is the key to fixing this.
Well, then maybe it's not the cause to our problems.
Some comments from the author:
1. It was a preliminary scratch report not meant to be exhaustive and
complete by any means. A comprehensive report of our findings will be
released soon.
2. I claim responsibility for any benchmarks gathered from Thumper and
the Linux/FASST/ZFS configuration.
On Feb 12, 2007, at 8:05 AM, Robert Petkus wrote:
Some comments from the author:
1. It was a preliminary scratch report not meant to be exhaustive
and complete by any means. A comprehensive report of our findings
will be released soon.
2. I claim responsibility for any benchmarks
Here's another website working on his rescue, myy prayers are for a safe return
of this CS icon.
http://www.helpfindjim.com/
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
Been using ZFS for a good bit now, and particularly on my laptop. Until
B60 is out, I've kind of refrained from using ZFS boot. Works fine, but
I ran into various issues, plus when it is upgrade time, that is a bit
brutal.
What I've been wanting is a way to make my laptop a bit more
redundant, so
On Feb 12, 2007, at 7:52 AM, Robert Milkowski wrote:
Hello Roch,
Monday, February 12, 2007, 3:54:30 PM, you wrote:
RP Duh!.
RP Long sync (which delays the next sync) are also possible on
RP a write intensive workloads. Throttling heavy writters, I
RP think, is the key to fixing this.
On Mon, 12 Feb 2007, Peter Schuller wrote:
Hello,
Often fsync() is used not because one cares that some piece of data is on
stable storage, but because one wants to ensure the subsequent I/O operations
are performed after previous I/O operations are on stable storage. In these
cases the
2007/2/12, Frank Hofmann [EMAIL PROTECTED]:
On Mon, 12 Feb 2007, Peter Schuller wrote:
Hello,
Often fsync() is used not because one cares that some piece of data is on
stable storage, but because one wants to ensure the subsequent I/O operations
are performed after previous I/O operations
comment below...
Uwe Dippel wrote:
Dear Richard,
Could it be that you are looking for the zfs clone subcommand?
I'll have to look into it !
I *did* look into it.
man zfs, /clone. This is what I read:
Clones
A clone is a writable volume or file system whose initial
contents are
Hi.
I have tested zfs for a while and is very impressed with the ease one
can create filesystems (tanks). I'm about to try it out on a atabeast
with 42 ata 400 GB disks for internal use, mailny as a fileserver. If
this goes well (as I assume it will) I'll consider to desploy zfs on a
larger
Peter Schuller wrote:
Hello,
Often fsync() is used not because one cares that some piece of data is on
stable storage, but because one wants to ensure the subsequent I/O operations
are performed after previous I/O operations are on stable storage. In these
cases the latency introduced by an
On 12-Feb-07, at 5:55 PM, Frank Hofmann wrote:
On Mon, 12 Feb 2007, Peter Schuller wrote:
Hello,
Often fsync() is used not because one cares that some piece of
data is on
stable storage, but because one wants to ensure the subsequent I/O
operations
are performed after previous I/O
On Mon, 12 Feb 2007, Toby Thain wrote:
[ ... ]
I'm no guru, but would not ZFS already require strict ordering for its
transactions ... which property Peter was exploiting to get fbarrier() for
free?
It achieves this by flushing the disk write cache when there's need to
barrier. Which
Then there is a failure, such that D1 becomes disconnected. ZFS
continues to write on D0. If D1 were to become reconnected, it would
get resilvered normally and all would be well.
But suppose instead there is a crash, and when the system reboots it is
connected only to D1, and D0 is
2007/2/12, Frank Hofmann [EMAIL PROTECTED]:
On Mon, 12 Feb 2007, Chris Csanady wrote:
This is true for NCQ with SATA, but SCSI also supports ordered tags,
so it should not be necessary.
At least, that is my understanding.
Except that ZFS doesn't talk SCSI, it talks to a target driver. And
Hello,
I am running SPEC SFS benchmark [1] on dual Xeon 2.80GHz box with 4GB memory.
More details:
snv_56, zil_disable=1, zfs_arc_max = 0x8000 #2GB
Configurations that were tested:
160 dirs/1 zfs/1 zpool/4 SAN LUNs
160 zfs'es/1 zpool/4 SAN LUNs
40 zfs'es/4 zpools/4 SAN LUNs
One zpool was
[EMAIL PROTECTED] said:
[b]How the ZFS striped on 7 slices of FC-SATA LUN via NFS worked [u]146 times
faster[/u] than the ZFS on 1 slice of the same LUN via NFS???[/b]
Well, I do have more info to share on this issue, though how it worked
faster in that test still remains a mystery. Folks may
Jeff Bonwick,
Do you agree that their is a major tradeoff of
builds up a wad of transactions in memory?
We loose the changes if we have an unstable
environment.
Thus, I don't quite understand why a 2-phase
approach to commits isn't done. First,
Do you agree that their is a major tradeoff of
builds up a wad of transactions in memory?
I don't think so. We trigger a transaction group commit when we
have lots of dirty data, or 5 seconds elapse, whichever comes first.
In other words, we don't let updates get stale.
Jeff
That said, actually implementing the underlying mechanisms may not be
worth the trouble. It is only a matter of time before disks have fast
non-volatile memory like PRAM or MRAM, and then the need to do
explicit cache management basically disappears.
I meant fbarrier() as a syscall exposed
That is interesting. Could this account for disproportionate kernel
CPU usage for applications that perform I/O one byte at a time, as
compared to other filesystems? (Nevermind that the application
shouldn't do that to begin with.)
No, this is entirely a matter of CPU efficiency in the current
27 matches
Mail list logo
