>AMD Geodes are 32-bit only. I haven't heard any mention that they will
>_ever_ be 64-bit. But, honestly, this and the Via chip aren't really
>ever going to be targets for Solaris. That is, they simply aren't (any
>substantial) part of the audience we're trying to reach with Solaris x86.
I'm
On 6/22/06, Bill Moore <[EMAIL PROTECTED]> wrote:
Hey Joe. We're working on some ZFS changes in this area, and if you
could run an experiment for us, that would be great. Just do this:
echo 'zil_disable/W1' | mdb -kw
We're working on some fixes to the ZIL so it won't be a bottleneck when
> 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
I guess the only hope is to find pin-compatible Xeons that are 64bit
to replace what is a large chassis with 24 slots of disks that has
specific motherboard form-factor, etc. We have 6 of these things from
a government grant that must be used for the stated purpose. So, yes,
we can buy product, bu
Erik Trimble wrote:
Dell (arrggh! Not THEM!) sells PowerEdge servers with plenty of PCI
slots and RAM, and 64-bit CPUs for around $1000 now. Hell, WE sell
dual-core x2100s for under $2k. I'm sure one can pick up a whitebox
single-core Opteron for around $1k. That's not unreasonable to ask
Artem Kachitchkine wrote:
AMD Geodes are 32-bit only. I haven't heard any mention that they
will _ever_ be 64-bit. But, honestly, this and the Via chip aren't
really ever going to be targets for Solaris. That is, they simply
aren't (any substantial) part of the audience we're trying to reac
AMD Geodes are 32-bit only. I haven't heard any mention that they will
_ever_ be 64-bit. But, honestly, this and the Via chip aren't really
ever going to be targets for Solaris. That is, they simply aren't (any
substantial) part of the audience we're trying to reach with Solaris x86.
Didn'
AMD Geodes are 32-bit only. I haven't heard any mention that they will
_ever_ be 64-bit. But, honestly, this and the Via chip aren't really
ever going to be targets for Solaris. That is, they simply aren't (any
substantial) part of the audience we're trying to reach with Solaris x86.
Also, r
On Thu, Jun 22, 2006 at 04:22:22PM -0700, Joe Little wrote:
> Again, the issue is the multiple fsyncs that NFS requires, and likely
> the serialization of those iscsi requests. Apparently, there is a
> basic latency in iscsi that one could improve upon with FC, but we are
> definitely in the all et
James C. McPherson wrote:
James C. McPherson wrote:
Jeff Bonwick wrote:
6420204 root filesystem's delete queue is not running
The workaround for this bug is to issue to following command...
# zfs set readonly=off /
This will cause the delete queue to start up and should flush your
queue.
Than
On 6/22/06, Jeff Bonwick <[EMAIL PROTECTED]> wrote:
> a test against the same iscsi targets using linux and XFS and the
> NFS server implementation there gave me 1.25MB/sec writes. I was about
> to throw in the towel and deem ZFS/NFS has unusable until B41 came
> along and at least gave me 1.25MB
James C. McPherson wrote:
Jeff Bonwick wrote:
6420204 root filesystem's delete queue is not running
The workaround for this bug is to issue to following command...
# zfs set readonly=off /
This will cause the delete queue to start up and should flush your
queue.
Thanks for the update. James,
> a test against the same iscsi targets using linux and XFS and the
> NFS server implementation there gave me 1.25MB/sec writes. I was about
> to throw in the towel and deem ZFS/NFS has unusable until B41 came
> along and at least gave me 1.25MB/sec.
That's still super slow -- is this over a 10Mb
On Thu, 22 Jun 2006, Joe Little wrote:
> On 6/22/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
> > Rich Teer wrote:
> > > On Thu, 22 Jun 2006, Joe Little wrote:
> > >
> > > Please don't top post.
> > >
> > >> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
> > >> I think it
Joe Little wrote:
On 6/22/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
Rich Teer wrote:
> On Thu, 22 Jun 2006, Joe Little wrote:
>
> Please don't top post.
>
>> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
>> I think it would still be ideal to allow tweaking of things
On 6/22/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
Rich Teer wrote:
> On Thu, 22 Jun 2006, Joe Little wrote:
>
> Please don't top post.
>
>> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
>> I think it would still be ideal to allow tweaking of things at runtime
>> to ma
Daniel Rock wrote:
Hi,
yesterday I implemented a simple hourly snapshot on my filesystems. I
also regularly initiate a manual "zpool scrub" on all my pools. Usually
the scrubbing will run for about 3 hours.
But after enabling hourly snapshots I noticed that zfs scrub is always
restarted if
On Thu, Jun 22, 2006 at 08:36:05PM +0200, Nicolai Johannes wrote:
> To the question whether we should care about being able to write files at all:
>
> I am not sure whether the following access checks are done by the
> file system layer, but what is with files in /dev/, named pipes and
> Unix Doma
To the question whether we should care about being able to write files at all:
I am not sure whether the following access checks are done by the file system
layer, but what is with files in /dev/, named pipes and Unix Domain Sockets?
Also for lockfiles, that may be removed by other users, writing
I am afraid, that I dislike the idea as well. You also need to record the
privileges of the process (perhaps the process chose to drop and set the new
privileges from time to time). It really complicates a safe and easy to verify
implementation.
To my mind, processes that will drop the new privi
Yes, lockfs works. It uses the ZIL - unless it's disabled where it
waits for all outstanding txgs to commit.
The man page doesn't say it's specific to UFS, but does mention
one specific UFS detail.
Darren J Moffat wrote On 06/22/06 11:19,:
Bill Sommerfeld wrote:
On Thu, 2006-06-22 at 13:01, R
>On Thu, 2006-06-22 at 10:55, [EMAIL PROTECTED] wrote:
>> To me, a "PRIV_OBJECT_MODIFY" which is required for any file modifying
>> operation would seem to be more useful as often a read-only user is
>> a worthwhile thing to have; perhaps mirrored with a PRIV_OBJECT_ACCESS
>> in case you want to p
On Thu, Jun 22, 2006 at 11:06:48AM -0700, Jonathan Adams wrote:
> On Thu, Jun 22, 2006 at 12:49:03PM -0500, Nicolas Williams wrote:
> > On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
> > > Concerning the reopen problem of files created in world writable
> > > directories: One may
On Thu, Jun 22, 2006 at 12:49:03PM -0500, Nicolas Williams wrote:
> On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
> > Concerning the reopen problem of files created in world writable
> > directories: One may use the following algorithm: First compute the
> > permissions of the n
On Thu, Jun 22, 2006 at 07:46:57PM +0200, Roch wrote:
>
> As I recall, the zfs sync is, unlike UFS, synchronous.
Uh, are you talking about sync(2), or lockfs -f? IIRC, lockfs -f is always
synchronous.
Cheers,
- jonathan
--
Jonathan Adams, Solaris Kernel Development
___
Yep. ZFS supports the ioctl (_FIOFFS) which 'lockfs -f' issues.
-- Prabahar.
Darren J Moffat wrote:
> Bill Sommerfeld wrote:
>> On Thu, 2006-06-22 at 13:01, Roch wrote:
>>> Is there a sync command that targets individual FS ?
>>
>> Yes. lockfs -f
>
> Does lockfs work with ZFS ? The man page
On Thu, 2006-06-22 at 10:55, [EMAIL PROTECTED] wrote:
> To me, a "PRIV_OBJECT_MODIFY" which is required for any file modifying
> operation would seem to be more useful as often a read-only user is
> a worthwhile thing to have; perhaps mirrored with a PRIV_OBJECT_ACCESS
> in case you want to prevent
As I recall, the zfs sync is, unlike UFS, synchronous.
-r
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
> Concerning the reopen problem of files created in world writable
> directories: One may use the following algorithm: First compute the
> permissions of the newly created file. For every permission granted
> to the user or group, c
On Thu, Jun 22, 2006 at 06:19:20PM +0100, Darren J Moffat wrote:
> Bill Sommerfeld wrote:
> >On Thu, 2006-06-22 at 13:01, Roch wrote:
> >> Is there a sync command that targets individual FS ?
> >
> >Yes. lockfs -f
>
> Does lockfs work with ZFS ? The man page appears to indicate it is very
> UFS
On Thu, 2006-06-22 at 13:19, Darren J Moffat wrote:
> > Yes. lockfs -f
>
> Does lockfs work with ZFS ? The man page appears to indicate it is very
> UFS specific.
all of lockfs does not. but, if truss is to believed, the ioctl used by
lockfs -f appears to. or at least, it returns without err
Bill Sommerfeld wrote:
On Thu, 2006-06-22 at 13:01, Roch wrote:
Is there a sync command that targets individual FS ?
Yes. lockfs -f
Does lockfs work with ZFS ? The man page appears to indicate it is very
UFS specific.
--
Darren J Moffat
___
z
On Thu, 2006-06-22 at 13:01, Roch wrote:
> Is there a sync command that targets individual FS ?
Yes. lockfs -f
- Bill
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailm
>Are VIA processor chips 64bit capable yet ?
No, I don't think so.
And Geode?
Casper
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
So, based on the below, there should be no reason why a flash-based
ZFS filesystem should need to do anything special to avoid problems.
That's a Good Thing.
I think that using flash as the system disk will be the way to go.
Using flash as read-only with a disk or memory for read-write wou
Rich Teer wrote:
On Thu, 22 Jun 2006, Joe Little wrote:
Please don't top post.
What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
I think it would still be ideal to allow tweaking of things at runtime
to make 32-bit systems more ideal.
I respectfully disagree. Even on x86
Bill Sommerfeld writes:
> On Thu, 2006-06-22 at 03:55, Roch wrote:
> > How about the 'deferred' option be on a leased basis with a
> > deadline to revert to normal behavior; at most 24hrs at a
> > time.
> why?
I'll trust your judgement over mine on this, so I won't
press. But i
Robert Milkowski writes:
> Hello Andrzej,
>
> Thursday, June 22, 2006, 11:30:23 AM, you wrote:
>
> AB> Hi zfs-discuss,
>
> AB> I have some questions about throttling on ZFS
>
> AB> 1) I know that throttling is activating while one sync is waiting
> AB> for another.
> AB> (http://blo
On Thu, 22 Jun 2006, Joe Little wrote:
Please don't top post.
> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
> I think it would still be ideal to allow tweaking of things at runtime
> to make 32-bit systems more ideal.
I respectfully disagree. Even on x86, 64-bits are c
Hi,
yesterday I implemented a simple hourly snapshot on my filesystems. I also
regularly initiate a manual "zpool scrub" on all my pools. Usually the
scrubbing will run for about 3 hours.
But after enabling hourly snapshots I noticed that zfs scrub is always
restarted if a new snapshot is cr
On Thursday 22 June 2006 17:15, you wrote:
> On Thu, Jun 22, 2006 at 11:55:05AM +0200, [EMAIL PROTECTED] wrote:
> > >Yes. It's kind of enticing.
> >
> > I'm not entirely clear as to the problem which it solves; I think
> > I'd much rather have a user which cannot modify anything.
>
> The "canonica
>Another concern would be: what UID owns files created by such processes?
I don't think it could be anything other than the current euid;
otherwise it is too easy to create files under a different uid.
>For non-basic privs we can always do things with the client's root
>credential and, when crea
On Thursday 22 June 2006 16:55, you wrote:
> >Yes, world readable/writable files can still be accessed by dropping =
> >the new privileges. One reason are library calls that need to read so=
> >me public files (like things in /etc). The need to manipulate or remo=
> >ve world writable files is hard
On Thu, Jun 22, 2006 at 11:55:05AM +0200, [EMAIL PROTECTED] wrote:
> >Yes. It's kind of enticing.
>
> I'm not entirely clear as to the problem which it solves; I think
> I'd much rather have a user which cannot modify anything.
The "canonical" example would be, I think, ssh-agent(1), although I'
You are right that vi or mktemp will not longer function with this approach.
On the other hand, only programs that will really know what they are doing
will drop basic privileges. I do not see a reason for most applications (like
vi) will do so.
Imagine a process has no identity (it dropped the
>
>Yes, world readable/writable files can still be accessed by dropping =
>the new privileges. One reason are library calls that need to read so=
>me public files (like things in /etc). The need to manipulate or remo=
>ve world writable files is harder to justify, on the other hand, worl=
>d writa
Well, I should weigh in hear.
I have been using ZFS with an iscsi backend and a NFS front end to my
clients. Until B41 (not sure what fixed this) I was getting 20KB/sec
for RAIDZ and 200KB/sec for just ZFS on on large iscsi LUNs
(non-RAIDZ) when I was receiving many small writes, such as untarrin
What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
I think it would still be ideal to allow tweaking of things at runtime
to make 32-bit systems more ideal.
On 6/21/06, Mark Maybee <[EMAIL PROTECTED]> wrote:
Yup, your probably running up against the limitations of 32-bit kern
On Thu, 2006-06-22 at 03:55, Roch wrote:
> How about the 'deferred' option be on a leased basis with a
> deadline to revert to normal behavior; at most 24hrs at a
> time.
why?
> Console output everytime the option is enabled.
in general, no. error messages to the console should be reserved
Hello Andrzej,
Thursday, June 22, 2006, 11:30:23 AM, you wrote:
AB> Hi zfs-discuss,
AB> I have some questions about throttling on ZFS
AB> 1) I know that throttling is activating while one sync is waiting
AB> for another.
AB> (http://blogs.sun.com/roller/page/roch?entry=the_dynamics_of_zfs)
AB>
Hello Craig,
Wednesday, June 21, 2006, 10:16:44 PM, you wrote:
CC> I have had a brief introduction to ZFS and while discussing it with some
other
CC> folks the question came up about use with multipathed storage. What, if any,
CC> configuration or interaction does ZFS have with a multipathed sto
Hello Roch,
Thursday, June 22, 2006, 9:55:41 AM, you wrote:
R> How about the 'deferred' option be on a leased basis with a
R> deadline to revert to normal behavior; at most 24hrs at a
R> time. Console output everytime the option is enabled.
I really hate when tools try to be more clever tha
>
>Concerning the reopen problem of files created in world writable dire=
>ctories:
>One may use the following algorithm:
>First compute the permissions of the newly created file.
>For every permission granted to the user or group, check whether the =
>corresponding identity-privilege is set. If n
Concerning the reopen problem of files created in world writable directories:
One may use the following algorithm:
First compute the permissions of the newly created file.
For every permission granted to the user or group, check whether the
corresponding identity-privilege is set. If not, the per
Yes, world readable/writable files can still be accessed by dropping the new
privileges. One reason are library calls that need to read some public files
(like things in /etc). The need to manipulate or remove world writable files is
harder to justify, on the other hand, world writable files ar
Concerning the large number of new privileges:
Yes, it is likely that a process may wish to drop all the privs together. On
the other hand, dropping only PRIV_FILE_IDENTITY_OWNER would still allow to
read files, write files, execute files, search files, but not change their
permissions and acces
>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, w
Hi zfs-discuss,
I have some questions about throttling on ZFS
1) I know that throttling is activating while one sync is waiting for another.
(http://blogs.sun.com/roller/page/roch?entry=the_dynamics_of_zfs)
Is it possible to throttle only selected processes (e.g. nfsd) ?
2) How can I obtain som
Darren J Moffat wrote:
> 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-"transa
Mark Shellenbaum wrote:
I thought that privileges only granted additional access that would
otherwise be denied by a file's permission bits/ACL. This sounds like
you want the presence of certain privileges to override permission bits?
There are two types of privileges in Solaris 10 onwards, 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 build
How about the 'deferred' option be on a leased basis with a
deadline to revert to normal behavior; at most 24hrs at a
time. Console output everytime the option is enabled.
-r
Torrey McMahon writes:
> Neil Perrin wrote:
> >
> > Of course we would need to stress the dangers of setting 'd
Martin, Marcia R writes:
> Did I miss something on this thread? Was the root cause of the
> 15-minute fsync <> actually determined?
>
I think so ;-)
-r
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/
63 matches
Mail list logo
