You probably want to add a -R / to your import command. That should keep
a node from automatically importing your zfs pool when it reboots after a crash.
See this thread...
http://www.opensolaris.org/jive/thread.jspa?threadID=13544&tstart=0
This message posted from opensolaris.org
__
On Wed, Apr 18, 2007 at 06:58:46PM -0700, Anton B. Rang wrote:
> For what it's worth, at a previous job I actually ported LZO to an
> OpenFirmware implementation. It's very small, doesn't rely on the standard
> libraries, and would be trivial to get running in a kernel. (Licensing might
> be an
Hi Robert, thanks for the information.
I understand from your words that you're more worried about overall filesystem
size rather than the number of files, yes? Is the number of files something I
should or should not worry about?
i.e., what are the differences (in stability, recoverability, per
On 4/19/07, Adam Lindsay <[EMAIL PROTECTED]> wrote:
16x hot swap SATAII hard drives (plus an internal boot drive)
Tyan S2895 (K8WE) motherboard
Dual GigE (integral nVidia ports)
2x Areca 8-port PCIe (8-lane) RAID drivers
2x AMD Opteron 275 CPUs (2.2GHz, dual core)
8 GiB RAM
The supplier is used
Why doesn't "zpool status -v" display the byte ranges of permanent
errors anymore, like it used to (before snv_57)?
I think it was a useful feature. For example, I have a pool with 17
permanent errors in 2 files with 700 MB each, but no ability to see
directly which one has the most errors or whic
On Apr 18, 2007, at 4:53 PM, J.P. King wrote:
http://www.sun.com/software/solaris/faqs/zfs.xml#q9
This says that networker should cope with ACLs RealSoonNow (mid
2006). It also says something which I didn't know, namely that
sun's tar and cpio will cope with ACLs... I guess they have a pax
For what it's worth, at a previous job I actually ported LZO to an OpenFirmware
implementation. It's very small, doesn't rely on the standard libraries, and
would be trivial to get running in a kernel. (Licensing might be an issue, of
course.)
This message posted from opensolaris.org
___
Hello eric,
Wednesday, April 18, 2007, 10:53:59 PM, you wrote:
ek> On Apr 18, 2007, at 2:35 AM, Richard L. Hamilton wrote:
>> Well, no; his quote did say "software or hardware". The theory is
>> apparently
>> that ZFS can do better at detecting (and with redundancy,
>> correcting) errors
>>
Hello Spencer,
Thursday, April 19, 2007, 2:28:30 AM, you wrote:
SS> On Apr 18, 2007, at 6:44 PM, Robert Milkowski wrote:
>> Hello Carson,
>>
>> Thursday, April 19, 2007, 1:22:17 AM, you wrote:
>>
>> CG> Robert Milkowski wrote:
>>
We did some tests with Linux (2.4 and 2.6) and it seems there
Joerg Schilling,
Stepping back into the tech discussion.
If we want a port of ZFS to Linux to begin, SHOULD the kitchen
sink approach be abandoned for the 1.0 release?? For later
releases, dropped functionality could be added in.
Suggested 1.0 Requirements
On Apr 18, 2007, at 6:44 PM, Robert Milkowski wrote:
Hello Carson,
Thursday, April 19, 2007, 1:22:17 AM, you wrote:
CG> Robert Milkowski wrote:
We did some tests with Linux (2.4 and 2.6) and it seems there's a
problem if you have thousands of nfs file systems - they won't
all be
mounted a
On Thu, Apr 19, 2007 at 12:36:38AM +0200, Joerg Schilling wrote:
> [EMAIL PROTECTED] wrote:
>
> > Actually sitting down and doing something hard (like porting
> > ZFS - one way or another - to Linux), well, the word
> > procrastination comes to mind and gee, isn't it easier to
> > come up with re
Adam:
> Does anyone have a clue as to where the bottlenecks are going to be with
> this:
>
> 16x hot swap SATAII hard drives (plus an internal boot drive)
> Tyan S2895 (K8WE) motherboard
> Dual GigE (integral nVidia ports)
> 2x Areca 8-port PCIe (8-lane) RAID drivers
> 2x AMD Opteron 275 CPUs (2
Hello Carson,
Thursday, April 19, 2007, 1:22:17 AM, you wrote:
CG> Robert Milkowski wrote:
>> We did some tests with Linux (2.4 and 2.6) and it seems there's a
>> problem if you have thousands of nfs file systems - they won't all be
>> mounted automatically, and even doing it manually (or in a s
Robert Milkowski wrote:
We did some tests with Linux (2.4 and 2.6) and it seems there's a
problem if you have thousands of nfs file systems - they won't all be
mounted automatically, and even doing it manually (or in a script with
a sleep between each mount) there seems to be a limit below 1000.
Hello Yaniv,
Wednesday, April 18, 2007, 3:44:57 PM, you wrote:
YA> Hello,
YA> I'd like to plan a storage solution for a system currently in production.
YA> The system's storage is based on code which writes many files to
YA> the file system, with overall storage needs currently around 40TB
YA>
We have 14 500GB PATA drives left over from another project. Given that ZFS
seems to prefer working with jbod's, does anyone know of an inexpensive
enclosure with an fcal interface to host the disks?
This message posted from opensolaris.org
___
zfs-
In asking about ZFS performance in streaming IO situations, discussion
quite quickly turned to potential bottlenecks. By coincidence, I was
wondering about the same thing.
Richard Elling said:
We know that channels, controllers, memory, network, and CPU bottlenecks
can and will impact actual p
[EMAIL PROTECTED] wrote:
> Actually sitting down and doing something hard (like porting
> ZFS - one way or another - to Linux), well, the word
> procrastination comes to mind and gee, isn't it easier to
> come up with reasons /not/ to do it?
>
> If someone really wanted ZFS on Linux, they'd just d
On Apr 18, 2007, at 12:47 PM, Dennis Clarke wrote:
Maybe with a definition of what a "backup" is and then some way to
achieve it. As far as I know the only real backup is one that can be
tossed into a vault and locked away for seven years. Or any arbitrary
amount of time within in reason. Lik
On 18-Apr-07, at 5:22 PM, J.P. King wrote:
Can we discuss this with a few objectives ? Like define "backup" and
then describe mechanisms that may achieve one? Or a really big
question that I guess I have to ask, do we even care anymore?
Personally I think you would benefit from some slig
Thanks, Richard, for your comments.
Richard Elling wrote:
so much data, so little time... :-)
:) indeed.
Adam Lindsay wrote:
Clearly, there are elements of the model that don't apply to our
sustained read/writes, so does anyone have any guidance (theoretical
or empirical) on what we could
Claus Guttesen wrote:
Gents, how come this thread - without any relation to zfs at all - is
discussed on this list? Do move this irrelevant thread to another
fora.
My intentions subscribing to this list was *not* to read about
lay-man's perception of this nor that license!
Because discussing
Adam Lindsay wrote:
Bart Smaalders wrote:
Adam Lindsay wrote:
Okay, the way you say it, it sounds like a good thing. I
misunderstood the performance ramifications of COW and ZFS's
opportunistic write locations, and came up with much more pessimistic
guess that it would approach random writes.
Bart Smaalders wrote:
Adam Lindsay wrote:
Okay, the way you say it, it sounds like a good thing. I misunderstood
the performance ramifications of COW and ZFS's opportunistic write
locations, and came up with much more pessimistic guess that it would
approach random writes. As it is, I have upp
> > Also, why not just punt to NDMP?
>
> While I like NDMP, the protocol is just a transport for blobs of data
> in vendor-specific data formats. We could put a ufsdump or star or
> 'zfs send' bag-o-bits in there, and call it ours. So it's a part of
> a solution, but not a complete thing.
NDMP
Hello Bart,
Thanks for the answers...
Bart Smaalders wrote:
Clearly, there are elements of the model that don't apply to our
sustained read/writes, so does anyone have any guidance (theoretical
or empirical) on what we could expect in that arena?
I've seen some references to a different ZFS m
Adam Lindsay wrote:
Okay, the way you say it, it sounds like a good thing. I misunderstood
the performance ramifications of COW and ZFS's opportunistic write
locations, and came up with much more pessimistic guess that it would
approach random writes. As it is, I have upper (number of data spin
On Apr 18, 2007, at 2:35 AM, Richard L. Hamilton wrote:
Well, no; his quote did say "software or hardware". The theory is
apparently
that ZFS can do better at detecting (and with redundancy,
correcting) errors
if it's dealing with raw hardware, or as nearly so as possible.
Most SANs
_can
Okay .. that is disk to disk or system to system. I can only assume
that you have large pipes of bandwidth ( 10 GE ) to move data around
with.
System to system. No, we have 100Mbit to the backup system. The systems
being backed up are small though, they are primarily people's desktops.
The
On Wed, Apr 18, 2007 at 02:42:15PM -0600, Robert Thurlow wrote:
> Nicolas Williams wrote:
>
> >Also, why not just punt to NDMP?
>
> While I like NDMP, the protocol is just a transport for blobs of data
> in vendor-specific data formats. We could put a ufsdump or star or
> 'zfs send' bag-o-bits i
On Wed, Apr 18, 2007 at 04:32:18PM -0400, Dennis Clarke wrote:
> I just finished installing Solaris 10 and ZFS at a manufacturing site
> that needs fast cheap storage. Its real tough to argue with ZFS once
> you see it in action. They were sold and I went ahead with a few
> terabytes of storage att
Nicolas Williams wrote:
Also, why not just punt to NDMP?
While I like NDMP, the protocol is just a transport for blobs of data
in vendor-specific data formats. We could put a ufsdump or star or
'zfs send' bag-o-bits in there, and call it ours. So it's a part of
a solution, but not a complete
On Wed, Apr 18, 2007 at 04:32:18PM -0400, Dennis Clarke wrote:
> On 4/18/07, J.P. King <[EMAIL PROTECTED]> wrote:
> >
> >> Can we discuss this with a few objectives ? Like define "backup" and
> >> then describe mechanisms that may achieve one? Or a really big
> >> question that I guess I have to
On 4/18/07, J.P. King <[EMAIL PROTECTED]> wrote:
> Can we discuss this with a few objectives ? Like define "backup" and
> then describe mechanisms that may achieve one? Or a really big
> question that I guess I have to ask, do we even care anymore?
Personally I think you would benefit from s
On 4/18/07, Nicolas Williams <[EMAIL PROTECTED]> wrote:
On Wed, Apr 18, 2007 at 03:47:55PM -0400, Dennis Clarke wrote:
> Maybe with a definition of what a "backup" is and then some way to
> achieve it. As far as I know the only real backup is one that can be
> tossed into a vault and locked away
Can we discuss this with a few objectives ? Like define "backup" and
then describe mechanisms that may achieve one? Or a really big
question that I guess I have to ask, do we even care anymore?
Personally I think you would benefit from some slightly different terms.
I would differentiate b
If the goal is to test ZFS as a root file system, could I suggest making a
virtual machine of b62-on-zfs available for download? This would reduce
duplicated effort and encourage new people to try it out.
This message posted from opensolaris.org
__
On Wed, Apr 18, 2007 at 03:47:55PM -0400, Dennis Clarke wrote:
> Maybe with a definition of what a "backup" is and then some way to
> achieve it. As far as I know the only real backup is one that can be
> tossed into a vault and locked away for seven years. Or any arbitrary
> amount of time within
Gents, how come this thread - without any relation to zfs at all - is
discussed on this list? Do move this irrelevant thread to another
fora.
My intentions subscribing to this list was *not* to read about
lay-man's perception of this nor that license!
regards
Claus
On 4/18/07, Shawn Walker <[E
On 18/04/07, Erik Trimble <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> And why would it need to be? As long as you don't distribute it as
> part of the Linux kernel or with a Linux kernel, you should be
> perfectly fine.
>
> (It is the end user who gets to assemble the bits; he cannot di
On 4/18/07, Bill Sprouse <[EMAIL PROTECTED]> wrote:
It seems that neither Legato nor NetBackup seem to lend themselves well to the
notion of lots of file systems within storage pools from an administration
perspective. Is there a preferred methodology for doing traditional backups to
tape fr
The kit that I promised for patching an install image
to support the profile-based install of systems with
zfs root file systems has been posted. It's at:
http://www.opensolaris.org/os/community/install/files/zfsboot-kit-20060418.i386.tar.bz2
Unpack it and see the README file for instructions.
so much data, so little time... :-)
Adam Lindsay wrote:
Hi folks. I'm looking at putting together a 16-disk ZFS array as a server, and
after reading Richard Elling's writings on the matter, I'm now left wondering
if it'll have the performance we expect of such a server. Looking at his
figures
Adam Lindsay wrote:
Hi folks. I'm looking at putting together a 16-disk ZFS array as a server, and
after reading Richard Elling's writings on the matter, I'm now left wondering
if it'll have the performance we expect of such a server. Looking at his
figures, 5x 3-disk RAIDZ sets seems like it
It seems that neither Legato nor NetBackup seem to lend themselves well to the
notion of lots of file systems within storage pools from an administration
perspective. Is there a preferred methodology for doing traditional backups to
tape from ZFS where there are hundreds or thousands of filesys
Darren J Moffat wrote:
> Until someone tries though you really never know what needs to be done.
> I would highly recommend getting LZO up and running as a Solaris
> kernel module - it might not be trivial or you could be lucky and it
> will "just work" . Writing a library and writing a kernel modu
Ricardo Correia wrote:
Darren J Moffat wrote:
I'd also highly recommend checking that this actually works for ZFS in
the kernel - which also means porting miniLZO to be a kernel module on
Solaris.
I don't see why it shouldn't. From the LZO homepage:
# Decompression is simple and */very/* fast
Darren J Moffat wrote:
>
> I'd also highly recommend checking that this actually works for ZFS in
> the kernel - which also means porting miniLZO to be a kernel module on
> Solaris.
I don't see why it shouldn't. From the LZO homepage:
# Decompression is simple and */very/* fast.
# Requires no mem
Ricardo Correia wrote:
Hi,
I don't know if this has been discussed before, but have you thought
about adding LZO compression to ZFS?
One zfs-fuse user has provided a patch which implements LZO compression,
and he claims better compression ratios *and* better speed than lzjb.
The miniLZO librar
[EMAIL PROTECTED] wrote on 04/18/2007 10:30:41 AM:
> Hi,
>
> I don't know if this has been discussed before, but have you thought
> about adding LZO compression to ZFS?
>
> One zfs-fuse user has provided a patch which implements LZO compression,
> and he claims better compression ratios *and
>It doesn't work that way. If the code can be considered to be part of a
>larger whole, then it gets covered by the GPL. Doesn't matter if you
>distribute the code section separately. The sticky part is what
>constitutes a "whole" - are kernel modules considered part of the Linux
>kernel as
Hi,
I don't know if this has been discussed before, but have you thought
about adding LZO compression to ZFS?
One zfs-fuse user has provided a patch which implements LZO compression,
and he claims better compression ratios *and* better speed than lzjb.
The miniLZO library is licensed under the G
Yes, it is:
SYNCHRONIZE_CACHE(10) opcode 0x35
SYNCHRONIZE_CACHE(16) opcode 0x91
[i]-- leon[/i]
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[EMAIL PROTECTED] wrote:
And why would it need to be? As long as you don't distribute it as
part of the Linux kernel or with a Linux kernel, you should be
perfectly fine.
(It is the end user who gets to assemble the bits; he cannot distribute
the results any further but an enduser is not bound b
Hi.
I think this is a bug:
interlope# zfs get setuid tank
NAME PROPERTY VALUE SOURCE
tank setuidoff local
interlope# zfs snapshot [EMAIL PROTECTED]
interlope# zfs get setuid [EMAIL PROTECTED]
NAME PROPERTY VALUE SOURCE
>Bob Bownes wrote:
>
>> I like the 'take a look at what Vertias' did suggestion. has anyone done
>> so?
>
>Does anyone *know* what Veritas did? I tried Google. It seems VxFS for
>Linux is not GPL.
And why would it need to be? As long as you don't distribute it as
part of the Linux kernel or w
Bob Bownes wrote:
I like the 'take a look at what Vertias' did suggestion. has anyone done
so?
Does anyone *know* what Veritas did? I tried Google. It seems VxFS for
Linux is not GPL.
I saw posts on the linux-kernel list expressing concerns about potential
GPL violations when accepting pat
Hi folks. I'm looking at putting together a 16-disk ZFS array as a server, and
after reading Richard Elling's writings on the matter, I'm now left wondering
if it'll have the performance we expect of such a server. Looking at his
figures, 5x 3-disk RAIDZ sets seems like it *might* be made to do
*If* someone were to do the port *and* there is demand for it, the lawyers
would settle out the license issues. Remember which is the dog and which
is the tail.
I like the 'take a look at what Vertias' did suggestion. has anyone done
so?
Toby Thain <[EMAIL PROTECTED]>
Sent by: [EMAIL PROT
Hello,
I'd like to plan a storage solution for a system currently in production.
The system's storage is based on code which writes many files to the file
system, with overall storage needs currently around 40TB and expected to reach
hundreds of TBs. The average file size of the system is ~100K
Toby Thain <[EMAIL PROTECTED]> wrote:
> > Therein lies the difference in perspective. Linux folks thinks it's
> > OpenSolaris's fault that ZFS cannot be integrated into Linux.
> > OpenSolaris folks do not think so.
>
> The OpenSolaris folks here seem to think it's Linux' fault. Impasse.
Let me r
Hello Simon,
Wednesday, April 18, 2007, 11:26:39 AM, you wrote:
S> It seems that only with the "script",no "dbca" GUI tool,the oracle
S> data file can be kept on the zfs volumes.
S> Any comments on this.
You had the same problems without using zfs so I assume it's not zfs
specific.
--
Best re
tester wrote:
Hi,
quoting from zfs docs
"The SPA allocates blocks in a round-robin fashion from the top-level vdevs. A
storage pool with multiple top-level vdevs allows the SPA to use dynamic striping to
increase disk bandwidth. Since a new block may be allocated from any of the top-level
vd
tester writes:
> Hi,
>
> quoting from zfs docs
>
> "The SPA allocates blocks in a round-robin fashion from the top-level
> vdevs. A storage pool with multiple top-level vdevs allows the SPA to
> use dynamic striping to increase disk bandwidth. Since a new block may
> be allocated from an
Hi,
quoting from zfs docs
"The SPA allocates blocks in a round-robin fashion from the top-level vdevs. A
storage pool with multiple top-level vdevs allows the SPA to use dynamic
striping to increase disk bandwidth. Since a new block may be allocated from
any of the top-level vdevs, the SPA imp
Dear All,
I made another testing(the last time:-)) but successful,so happy ?!
and belows are the detail.
*) Requirements:
Create oracle 9i data file over Solaris 10 zfs volume
*) Failure History:
With "dbca" GUI,db creation always failure due to '/device' space not
enough,it complains:
You don'
is cache flushing part of the SCSI protocol? If not, how does ZFS become aware
of the array specific command?
Thanks
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailma
Hello Richard,
Wednesday, April 18, 2007, 7:35:24 AM, you wrote:
RLH> Well, no; his quote did say "software or hardware".
Right, I missed that.
RLH> The theory is apparently
RLH> that ZFS can do better at detecting (and with redundancy, correcting)
errors
RLH> if it's dealing with raw hardw
Richard L. Hamilton writes:
> Well, no; his quote did say "software or hardware". The theory is apparently
> that ZFS can do better at detecting (and with redundancy, correcting) errors
> if it's dealing with raw hardware, or as nearly so as possible. Most SANs
> _can_ hand out raw LUNs as we
Dan Mick writes:
> Robert Milkowski wrote:
> > Hello Dan,
> >
> > Tuesday, April 17, 2007, 9:44:45 PM, you wrote:
> >
> How can this work? With compressed data, its hard to predict its
> final size before compression.
> >>> Because you are NOT compressing the file only compr
71 matches
Mail list logo
