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 t
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 buil
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.
> Concerni
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:
Think about a process that runs under user bar and group foo that have all
basic privileges set and tries to access
a
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 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 you
>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
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
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 privilege
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
Neil,
I think it might be wise to look at this problem from the perspective
of an application (e.g. a simple database) designer taking into account
all the new things that Solaris ZFS provides.
In case of ZFS the designer does not have to worry about consistency
of the on-disk file system format
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 present
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 spe
ZFS relies on the underlying multipathing software. In most cases that
is mpixo/traffic-manager.
Craig Cory wrote:
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 interac
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 Instru
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: zfs-discuss@opensolari
Neil Perrin wrote:
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
>Just so I am understanding this correctly. All of the PRIV_IDENTITY_*
>privs look only at euid or egid?
I find the formulation a bit strange; no operation in the kernel,
except for the much maligned access() use anything other than effective
ids.
Could we please have an example of what these
Neil Perrin wrote:
Of course we would need to stress the dangers of setting 'deferred'.
What do you guys think?
That's the key: Be very explicit about what the option does and the side
effects.
___
zfs-discuss mailing list
zfs-discuss@opensolaris
Nicolai Johannes wrote:
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_own
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 initia
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
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 secpolicy_vnode_acc
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
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
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 r
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
>
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
On 6/20/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
Holger Berger wrote:
> On 6/19/06, Eric Schrock <[EMAIL PROTECTED]> wrote:
>> Simply because we erred on the side of caution. The fewer metachacters,
>> the better. It's easy to change if there's enough interest.
>
> You may want to change
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.
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 r
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 n
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
http://mail.opensolaris.org/mailman/listinfo/
Roch wrote On 06/21/06 07:31,:
15 minutes to do a fdsync is way outside the slowdown usually seen.
The footprint for 6413510 is that when a huge amount of
data is being written non synchronously and a fsync comes in for the
same filesystem then all the non-synchronous data is also force
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
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
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 environmen
> 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 OpenSola
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 multi
15 minutes to do a fdsync is way outside the slowdown usually seen.
The footprint for 6413510 is that when a huge amount of
data is being written non synchronously and a fsync comes in for the
same filesystem then all the non-synchronous data is also forced out
synchronously. So is there
Hello zfs-discuss,
Simple test 'ptime find /zfs/filesystem >/dev/null' with 2GB RAM.
After second, third, etc. time still it reads a lot from disks while
find is running (atime is off).
on x64 (Opteron) it doesn't.
I guess it's due to 512MB heap limit in kernel for its cache.
::memst
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
This just published:
http://blogs.sun.com/roller/page/roch?entry=the_dynamics_of_zfs
-r
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
This just published:
http://blogs.sun.com/roller/trackback/roch/Weblog/the_dynamics_of_zfs
-r
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
I like to alter my suggestion for one privilege and updated the list of
affected syscalls:
PRIV_FILE_IDENTITY_OWNER:
Allow the process to benefit from its supplemental rights associated with its
identity (euid, egid and associated groups) during file or directory operations
that require ownersh
>Well operating systems that *do* get used to build devices *do*
>have these mount options for this purpose, so I imagine that
>someone who does this kind of thing thinks they're worthwhile.
Thinking that soemthing is worthwhile and having done the analysis
to proof that it is worthwhile are two
46 matches
Mail list logo
