Hello Roch,
Wednesday, June 21, 2006, 2:31:25 PM, you wrote:
R This just published:
R
R http://blogs.sun.com/roller/trackback/roch/Weblog/the_dynamics_of_zfs
Proper link is: http://blogs.sun.com/roller/page/roch?entry=the_dynamics_of_zfs
--
Best regards,
Robert
Hi experts,
I have few issues about ZFS and virtualization:
[b]Virtualization and performance[/b]
When filesystem traffic occurs on a zpool containing only spindles dedicated to
this zpool i/o can be distributed evenly. When the zpool is located on a lun
sliced from a raid group shared by
I am also interested in writing some test cases that
will check the correct semantic of access checks on
files with different permissions and with different
privileges set/unset by the process. Are there
already file access test cases at Sun I may expand?
Should test suites for OpenSolaris
Actually, while Seagate's little white paper doesn't explicitly say so, the
FLASH is used for a write cache and that provides one of the major benefits:
Writes to the disk rarely need to spin up the motor. Probably 90+% of all
writes to disk will fit into the cache in a typical laptop
Hi Constantin,
The basic problem with regular snapshotting is that you end up managing so
many of them. Wouldn't it be nice if you could assign an expiration date to a
snapshot?
The only reason you want the snapshot removed is because you don't want your
pool to become full. IIRC VxFS has a
The vi we were doing was a 2 line file. If you just vi a new file, add
one line and exit it would take 15 minutes in fdsynch. On
recommendation of a workaround we set
set zfs:zil_disable=1
after the reboot the fdsynch is now 0.1 seconds. Now I have no idea if it was this setting or the fact
Well this does look more and more like a duplicate of:
6413510 zfs: writing to ZFS filesystem slows down fsync() on other files in the
same FS
Neil
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
Sean Meighan writes:
The vi we were doing was a 2 line file. If you just vi a new file, add
one line and exit it would take 15 minutes in fdsynch. On recommendation
of a workaround we set
set zfs:zil_disable=1
after the reboot the fdsynch is now 0.1 seconds. Now I have no idea
Nicolai Johannes wrote:
For my Google Summer of Code project for OpenSolaris, my job is to think about
new basic privileges. I like to propose five new basic privileges that relate
with file system access checks and may be used for daemons like ssh or
ssh-agent that (after starting up) never
Roch wrote:
Sean Meighan writes:
The vi we were doing was a 2 line file. If you just vi a new file, add
one line and exit it would take 15 minutes in fdsynch. On recommendation
of a workaround we set
set zfs:zil_disable=1
after the reboot the fdsynch is now 0.1 seconds. Now I
Torrey McMahon wrote On 06/21/06 10:29,:
Roch wrote:
Sean Meighan writes:
The vi we were doing was a 2 line file. If you just vi a new file,
add one line and exit it would take 15 minutes in fdsynch. On
recommendation of a workaround we set
set zfs:zil_disable=1
after the
Hello Neil,
Wednesday, June 21, 2006, 6:41:50 PM, you wrote:
NP Torrey McMahon wrote On 06/21/06 10:29,:
Roch wrote:
Sean Meighan writes:
The vi we were doing was a 2 line file. If you just vi a new file,
add one line and exit it would take 15 minutes in fdsynch. On
recommendation
On Wed, Jun 21, 2006 at 10:41:50AM -0600, Neil Perrin wrote:
Why is this option available then? (Yes, that's a loaded question.)
I wouldn't call it an option, but an internal debugging switch that I
originally added to allow progress when initially integrating the ZIL.
As Roch says it really
Nicolas Williams wrote:
On Wed, Jun 21, 2006 at 10:41:50AM -0600, Neil Perrin wrote:
Why is this option available then? (Yes, that's a loaded question.)
I wouldn't call it an option, but an internal debugging switch that I
originally added to allow progress when initially integrating
Robert Milkowski wrote On 06/21/06 11:09,:
Hello Neil,
Why is this option available then? (Yes, that's a loaded question.)
NP I wouldn't call it an option, but an internal debugging switch that I
NP originally added to allow progress when initially integrating the ZIL.
NP As Roch says it
Thank you for your hints.
I already investigated the zfs/ufs/tmpfs code when I wrote my proposal.
When I wrote check if set, I mean doing this with new secpolicy_vnode_*
functions. The check for the already existing privileges would of course stay
in secpolicy_vnode_owner and
I checked into this and got some information from
the install group. What I learned is this: the
process of creating a flash archive is just a matter
of using cpio/pax to make a copy of the contents
of an installed system. A flash archive doesn't
contain any information about the configuration
On Wed, 2006-06-21 at 14:15, Neil Perrin wrote:
Of course we would need to stress the dangers of setting 'deferred'.
What do you guys think?
I can think of a use case for deferred: improving the efficiency of a
large mega-transaction/batch job such as a nightly build.
You create an initially
Did I miss something on this thread? Was the root cause of the
15-minute fsync every actually determined?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of eric kustarz
Sent: Wednesday, June 21, 2006 2:12 PM
To: [EMAIL PROTECTED]
Cc:
I have had a brief introduction to ZFS and while discussing it with some other
folks the question came up about use with multipathed storage. What, if any,
configuration or interaction does ZFS have with a multipathed storage setup -
however it may be managed.
thanks!
Craig Cory
Senior
Lori Alt wrote:
zfs-aware.
So the answer to your question is that you can create a
flash archive from this system with zfs filesystems, but
until the install software is zfs-aware, you can't use
the archive to create a system with zfs pools and datasets.
yeah that sort of stuff is usually
After reading the mails concerning my proposal on the list, I realized the
points that were not clear enough in my proposal.
First of all, I totally aggree with all your statements, if the new privileges
were not basic privileges.
All new privileges are basic privileges. So they will be
Yup, your probably running up against the limitations of 32-bit kernel
addressability. We are currently very conservative in this environment,
and so tend to end up with a small cache as a result. It may be
possible to tweak things to get larger cache sizes, but you run the risk
of starving out
Nicolai Johannes wrote:
After reading the mails concerning my proposal on the list, I realized the
points that were not clear enough in my proposal.
First of all, I totally aggree with all your statements, if the new privileges
were not basic privileges.
All new privileges are basic
http://www.tech-recipes.com/solaris_system_administration_tips1446.html
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Processes like ssh-agent that do not need their identiity may drop =
them. An exploit too these processes may not exploit the fact, that t=
he euid/groups of the process allow some file operations that are den=
ied to everyone. Only files that are globally readable/writable/execu=
table may still
On Thu, Jun 22, 2006 at 01:01:38AM +0200, [EMAIL PROTECTED] wrote:
I'm not sure if I like the name, then; nor the emphasis on the
euid/egid (as those terms are not commonly used in the kernel;
there's a reason why the effective uid was cr-cr_uid and not cr_euid.
In other words, what your are
On 6/21/06, Lori Alt [EMAIL PROTECTED] wrote:
I checked into this and got some information from
the install group. What I learned is this: the
process of creating a flash archive is just a matter
of using cpio/pax to make a copy of the contents
of an installed system. A flash archive doesn't
On Thu, Jun 22, 2006 at 02:45:50AM +0200, Nicolai Johannes wrote:
Spo as I have understood you, explaining the new privileges with the
term anonymous user would be better? I actually thought about that
idea, but there is a subtle difference:
Hmmm, no I have no good name for it.
Concerning
Bill Sommerfeld wrote:
On Wed, 2006-06-21 at 14:15, Neil Perrin wrote:
Of course we would need to stress the dangers of setting 'deferred'.
What do you guys think?
I can think of a use case for deferred: improving the efficiency of a
large mega-transaction/batch job such as a nightly build.
Anton B. Rang wrote:
Actually, while Seagate's little white paper doesn't explicitly say so, the
FLASH is used for a write cache and that provides one of the major benefits:
Writes to the disk rarely need to spin up the motor. Probably 90+% of all
writes to disk will fit into the cache in a
31 matches
Mail list logo
