On Fri, Ben Rockwood wrote:
eric kustarz wrote:
So i'm guessing there's lots of files being created over NFS in one
particular dataset?
We should figure out how many creates/second you are doing over NFS (i
should have put a timeout on the script). Here's a real simple one
(from your
On Fri, Dec 08, 2006 at 12:15:27AM -0800, Ben Rockwood wrote:
Clearly ZFS file creation is just amazingly heavy even with ZIL
disabled. If creating 4,000 files in a minute squashes 4 2.6Ghz Opteron
cores we're in big trouble in the longer term. In the meantime I'm
going to find a new home
If your database performance is dominated by sequential reads, ZFS may not be
the best solution from a performance perspective. Because ZFS uses a
write-anywhere layout, any database table which is being updated will quickly
become scattered on the disk, so that sequential read patterns become
Jim Davis wrote:
eric kustarz wrote:
What about adding a whole new RAID-Z vdev and dynamicly stripe across
the RAID-Zs? Your capacity and performance will go up with each
RAID-Z vdev you add.
Thanks, that's an interesting suggestion.
This has the benefit of allowing you to grow into your
Spencer Shepler wrote:
Good to hear that you have figured out what is happening, Ben.
For future reference, there are two commands that you may want to
make use of in observing the behavior of the NFS server and individual
filesystems.
There is the trusty, nfsstat command. In this case, you
Bill Moore wrote:
On Fri, Dec 08, 2006 at 12:15:27AM -0800, Ben Rockwood wrote:
Clearly ZFS file creation is just amazingly heavy even with ZIL
disabled. If creating 4,000 files in a minute squashes 4 2.6Ghz Opteron
cores we're in big trouble in the longer term. In the meantime I'm
going
Ben Rockwood wrote:
Bill Moore wrote:
On Fri, Dec 08, 2006 at 12:15:27AM -0800, Ben Rockwood wrote:
Clearly ZFS file creation is just amazingly heavy even with ZIL
disabled. If creating 4,000 files in a minute squashes 4 2.6Ghz
Opteron cores we're in big trouble in the longer term. In
Hi All,
we have some ZFS pools on production with more than 100s fs and more than 1000s
snapshots on them.
Now we do backups with zfs send/receive with some scripting but I'm searching
for a way to mirror each zpool to an other one for backup purposes (so
including all snapshots!). Is that
On Dec 8, 2006, at 05:20, Jignesh K. Shah wrote:
Hello ZFS Experts
I have two ZFS pools zpool1 and zpool2
I am trying to create bunch of zvols such that their paths are
similar except for consisent number scheme without reference to the
zpools that actually belong. (This will allow me
I am already using symlinks.
But the problem is the ZFS framework won't know about them .
I would expect something like this from ZVOL specially abstracting the
poolname path from zvol.
Specially since many database will store the path names in their
metadata and is hard to change later on.
Yes. But its going to be a few months.
i'll presume that we will get background disk scrubbing for free once
you guys get bookmarking done. :)
--
Regards,
Jeremy
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
Could be NFS synchronous semantics on file create (followed by
repeated flushing of the write cache). What kind of storage are you
using (feel free to send privately if you need to) - is it a thumper?
It's not clear why NFS-enforced synchronous semantics would induce
different behavior than
Jignesh K. Shah wrote:
I am already using symlinks.
But the problem is the ZFS framework won't know about them .
Can you explain how this knowledge would benefit the combination
of ZFS and databases? There may be something we could leverage here.
I would expect something like this from ZVOL
On 12/8/06, Jochen M. Kaiser [EMAIL PROTECTED] wrote:
Dear all,
we're currently looking forward to restructure our hardware environment for
our datawarehousing product/suite/solution/whatever.
We're currently running the database side on various SF V440's attached via
dual FC to our SAN
Jochen M. Kaiser wrote:
Dear all,
we're currently looking forward to restructure our hardware environment for
our datawarehousing product/suite/solution/whatever.
cool.
We're currently running the database side on various SF V440's attached via
dual FC to our SAN backend (EMC DMX3) with
The way I see it benefits is because it will mean less stray threads
which is what I would call symlinks.
Say if the mount option for zvols are used to define that purpose, ZFS
metadata will always know how it is really being used. Also if someday
we come up with the framework to dump the
Jim Mauro wrote:
Could be NFS synchronous semantics on file create (followed by
repeated flushing of the write cache). What kind of storage are you
using (feel free to send privately if you need to) - is it a thumper?
It's not clear why NFS-enforced synchronous semantics would induce
On Dec 9, 2006, at 8:59 , Jim Mauro wrote:
AnywayI'm feeling rather naive' here, but I've seen the NFS
enforced synchronous semantics phrase
kicked around many times as the explanation for suboptimal
performance for metadata-intensive
operations when ZFS is the underlying file system, but
On Dec 9, 2006, at 8:59 , Jim Mauro wrote:
AnywayI'm feeling rather naive' here, but I've seen the NFS
enforced synchronous semantics phrase
kicked around many times as the explanation for suboptimal
performance for metadata-intensive
operations when ZFS is the underlying file
Anton,
On 12/8/06 7:18 AM, Anton B. Rang [EMAIL PROTECTED] wrote:
If your database performance is dominated by sequential reads, ZFS may not be
the best solution from a performance perspective. Because ZFS uses a
write-anywhere layout, any database table which is being updated will quickly
20 matches
Mail list logo
