date:20070419

Hello Tim,

Thursday, April 19, 2007, 10:32:53 AM, you wrote:

TT> Hi

TT> This is a bit off topic...but as  Bill mentioned SAM-FS...my job at Sun
TT> is working in a group focused on ISV's in the archiving space (Symantec
TT> Enterprise Vault, Open Text LEA, CA Message Manager, FileNet, Mobius, 
TT> AXS-One etc etc)...we see a strong interest from some of them in using
TT> SAM-FS because is solves the problem of backing up _archived _data. I 
TT> just completed some interesting projects with Symantec using SAMBA + 
TT> SAM-FS (Enterprise Vault is a Windows App).

TT> One thing we have considered is using SAM-FS & ZFS together on a 
TT> serverthe archived data is written into SAM-FS by the application 
TT> which later copies it to  ZFS (which is then a mid-tier disk archive) 
TT> and tape (last tier). SAM-FS is being Open Sourced real soon (for people
TT> who care about that) also runs on x64 now.

TT> SAM-FS + ZFS + Thumper (Sun Fire x4500) + tape could be a nice back end
TT> for an archiving application.

Does SAM-FS work with ZFS right now? I thought that it works only with
QFS...?

-- 
Best regards,
 Robertmailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Bottlenecks in building a system

2007-04-19 Thread Adam Lindsay


Nicholas Lee wrote:
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
...



I guess my questions are:
- Does anyone out there have a clue where the potential bottlenecks
might be?


Get INTEL GigE!!! NVidia aren't as fast and Intel drivers are very 
good.


yes, I've been made aware of a lot of pushback on the nVidia 
drivers/hardware recently, and so I'll aim to put a better networking 
card in, as well.


If it is just storage then it might not matter whether you use Opterons 
or Xeons. Since you are just feeding stuff from the disk to the nic, 
things like HyperTransport are probably not so much of a win.


Not sure if Tyan have Intel 3U systems, maybe look at Supermicro instead.


It's just the mobo, at the moment, from Tyan. The local vendor has his 
standard 3U chassis that he uses.



- Is there anywhere where I can save a bit of money? (For example,
might the SuperMicro AOC-SAT2-MV8 hanging off the PCI-X slots
provide enough bandwidth to the disks?)


I'm using this card, seems to work fine.  I posted some numbers on this 
at [1].


That's good, interesting stuff. Here are a few thoughts going through my 
head:
- The bus interconnect is more critical with software RAID than 
hardware, no? For each block, more data has to go to the CPU.
- I'm very lured by the performance offered by two 8-lane PCIe cards 
(full duplex, mind...) over PCI-X cards running (with the selected mobo) 
at 133MHz and 100MHz.
- I'll be trying to wring as much IO performance as possible from 15 
drives -- most likely 3x 5-disk RAIDZ sets. While your figures are 
encouraging, I'm not sure they wouldn't hit a ceiling before they scale 
up to where I want to be. (It looks like they won't, but I'm not sure.)


This is a [2] 2U 12 disk system with two Dual Core 2GHz Xeons, 4Gb.  
2x2x500Gb mirror and 5xRaid2z with Seagate ES 500Gb drives. Rellings 
reply might be useful as well.


Raid cards a definitely a waste of money if you are using zfs.


Which is exactly what I thought going into this, but I am not aware of 
that many choices in JBOD controllers, especially running off the PCIe bus.



Thanks for the time and pointers,
adam
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zpool status -v

2007-04-19 Thread Ricardo Correia

eric kustarz wrote:
> Two reasons:
> 1) cluttered the output (as the path name is variable length).  We
> could perhaps add another flag (-V or -vv or something) to display the
> ranges.
> 2) i wasn't convinced that output was useful, especially to most
> users/admins.
>
> If we did provide the range information, how would you actually use
> that information?
>
> or would providing the number of checksum errors per file be what
> you're really looking for?
>

I agree that the current display is more appropriate as a default.
But yes, I think adding a -vv flag to show the range output would be
useful. It seems interesting from an observability standpoint, since I
could easily tell how much damage did the file get. Simply telling the
number of checksum errors per file would be useful too, but not as
useful it was since each checksum error can be between 512 bytes and 128 KB.

> ps: could you send me the 'zpool status -v' output for curiosity's sake
Sure :)

[EMAIL PROTECTED]:~/zfs/repos/trunk/src/zfs-fuse$ sudo zpool status -v
  pool: pen
 state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scrub: scrub completed with 22 errors on Thu Apr 19 16:31:56 2007
config:

NAMESTATE READ WRITE CKSUM
pen ONLINE   0 044
  sdb2  ONLINE   0 044

errors: Permanent errors have been detected in the following files:

/pen/compr/vmware-img.tar
/pen/compr2/vmware-img.tar

  pool: ruben
 state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scrub: scrub completed with 1 errors on Thu Apr 19 16:33:04 2007
config:

NAMESTATE READ WRITE CKSUM
ruben   ONLINE   0 0   106
  sda   ONLINE   0 0   106

errors: Permanent errors have been detected in the following files:

/ruben/ptwiki-20060916-pages-meta-history.xml.7z

Aren't USB pen drives great? (not!)
For curiosity sake, that "pen" pool is in a 2 GB partition inside a 4 GB
pen drive I bought recently, and both vmware-img.tar files have around
750 MB each.

The "ruben" pool is a *very flaky* 128 MB pen drive that a friend gave
to me since it was completely unusable with other filesystems.
For the record, in this filesystem, I set copies=3, filled the pool with
random files and even then the scrub found 1 permanent error!

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Re: Multi-tera, small-file filesystems


Yaniv Aknin wrote:

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, performance, 
manageability... etc) between a 25TB filesystem with 2^35 files and a 25TB 
filesystem with 1,000 files, each 25GB?


I don't think we anticipate problems, but I'm not sure there are a lot
of people who have done this, yet.  We do know of such limitations in UFS,
and other file systems, which do not exist in ZFS, by design.
 -- richard
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Preferred backup mechanism for ZFS?

2007-04-19 Thread Tim Thomas


Hi Robert

no, SAM-FS does not work with ZFS, it is still tied to QFS i.e. the SAM 
piece cannot archive data straight out of a ZFS file system.


I am a big fan of SAM-FS so forgive me if I expand a little on the topic...

The way a solution like this would work is that you would build a SAM-FS 
file system on some of the disks and a ZFS file system on some others. 
Maybe SAM-FS would be on "fast" disks and ZFS on "slow" disks.


Your application would write files into the SAM-FS file system. In my 
work this application would be an archiving application that has 
extracted data (e.g emails) out of a business application and now wants 
somewhere to put the archived data.


SAM-FS can then make copies of the files (back them up) in to the ZFS 
file system and to tape (at the same or another time) up to a maximum of 
4 copies...so from SAM-FS's perspective ZFS is being treated as a disk 
archiveSAM-FS does not care that it writing to a ZFS file system 
..it just sees a directory that it can treat as a target to make backup 
copies of data into. ZFS is nice here because it can be used with JBODs 
and can do software RAID.


SAM-FS (and it's little brother QFS which is the file system without the 
archiving), both do software RAID, but only RAID-0...so the underlying 
"disks" need to be h/ware RAID protected or logical volumes built with 
something like Solaris Volume Manager.


So (you may ask) why would anyone want to do this ? Well...think of the 
SAM-FS file system as a cache...once it has backed up a file to a disk 
and/or tape archive it can be configured to "release" the file's data 
blocks and just leave a stub behind. The file is now viewed as off-line 
(Hey, this looks like HSM!) - There are a rich set of rules you can 
define around when this happens - the simplest is to do it when the file 
system passes a high %full watermark...in short..IT NEVER FILLS UP!


So that is pretty cool...so here is the next really nice bit, the files 
are backed up continuously (once again. there are a rich set of rules 
around this)...no huge backup windows while millions of small files are 
backed up like a conventional backup product...SAM-FS will back them up 
throughout the day...also, NO  INCREMENTAL BACKUPS required...we are 
working at a per file level here. If a  file is written and never 
changes SAM-FS will make copies of it and then we are done..we never 
copy it again unless it changes...there is just one image of the file 
system.


SAM-FS handles all the interaction with tape libraries etc...no extra 
s/ware required.


So, what if you open a released file ? Once you read past the end of the 
stub SAM-FS stages the rest of the data back from archivesit is 
transparent...and it really is...if the file is having to come back from 
tape the long delays can cause application issues sometimes but files 
coming back from disk archives come back so fast that there are no problems.


You can access SAM-FS via NFS and CIFS/SAMBA safely. NFS client need to 
support correct handling of the NFS EJUKEBOX error code...Solaris's does.


Now, what if you loose a whole file system with millions of files in it. 
Recovering that from backups is no fun. part of managing SAM-FS is 
taking regular backups of the metadata...this is effectively a snapshot. 
If a  file system is lost due to catastrophic h/ware failure then you 
can restore the meta into an empty SAM-FS file system (which can be 
smaller or larger than the original) in a  few minutes and bingo, all 
the data is there again..with all the files off-line.


SAM-FS management is all via the command line or via a really nice Web 
based UI. I won't pretend that it is as easy as ZFS to create a SAM-FS 
file system 'cause it aint'..but heck, it's fun once you get with 
it...and the GUI certainly makes life much easier.


So..what is the "bad" stuff, other than no RAID-Z equivalent, well: you 
cannot grow a SAM-FS file system on-line..it needs to be unmounted 
first; No snapshots (other than the meta data based ones); you have to 
back up the meta data regularly as that is effectively the backup 
catalog which can be a drag but the procedures are well defined.


There is other stuff that SAM-FS can do such as shared Global File 
system support in SAN's etc...but I have gone on enough!!


Rgds

Tim



Robert Milkowski said the following :

Hello Tim,

Thursday, April 19, 2007, 10:32:53 AM, you wrote:

TT> Hi

TT> This is a bit off topic...but as  Bill mentioned SAM-FS...my job at Sun
TT> is working in a group focused on ISV's in the archiving space (Symantec
TT> Enterprise Vault, Open Text LEA, CA Message Manager, FileNet, Mobius, 
TT> AXS-One etc etc)...we see a strong interest from some of them in using
TT> SAM-FS because is solves the problem of backing up _archived _data. I 
TT> just completed some interesting projects with Symantec using SAMBA + 
TT> SAM-FS (Enterprise Vault is a Windows App).


TT> One thing we have considered is using SAM-FS & ZFS together

Re: [zfs-discuss] Bottlenecks in building a system


additional comments below...

Adam Lindsay wrote:
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 performance, at least for large configs.
Modeling these bottlenecks is possible, but will require more work in
the tool.  If you know the hardware topology, you can do a 
back-of-the-napkin

analysis, too.


Well, I'm normally a Mac guy, so speccing server hardware is a bit of a 
revelation for me. I'm trying to come up with a ZFS storage server for a 
networked multimedia research project which hopefully has enough oomph 
to be a nice resource that outlasts the (2-year) project, but without 
breaking the bank.


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)


Be sure to check the actual bandwidth of the drives when installed in the
final location.  We have been doing some studies on the impact of vibration
on performance and reliability.  If your enclosure does not dampen vibrations,
then you should see reduced performance, and it will be obvious for streaming
workloads.  There was a thread about this a year or so ago regarding thumpers,
but since then we've seen it in a number of other systems, too.  There have
also been industry papers on this topic.


Tyan S2895 (K8WE) motherboard
Dual GigE (integral nVidia ports)


All I can add to the existing NIC comments in this thread is that Neptune kicks
ass.  The GbE version is:
   
http://www.sun.com/products/networking/ethernet/sunx8quadgigethernet/index.xml
... but know that I don't set pricing :-0


2x Areca 8-port PCIe (8-lane) RAID drivers


I think this is overkill.


2x AMD Opteron 275 CPUs (2.2GHz, dual core)


This should be a good choice.  For high networking loads, you can burn a lot
of cycles handling the NICs.  For example, using Opterons to drive the dual
10GbE version of Neptune can pretty much consume a significant number of cores.
I don't think your workload will come close to this, however.


8 GiB RAM


I recommend ECC memory, not the cheap stuff... but I'm a RAS guy.

The supplier is used to shipping Linux servers in this 3U chassis, but 
hasn't dealt with Solaris. He originally suggested 2GiB RAM, but I hear 
things about ZFS getting RAM hungry after a while. I dug up the RAID 
controllers after a quick look on Sun's HCL, but they're pricy for 
something that's just going to give JBOD access (but the bus 
interconnect looks to be quick, on the other hand).


Pretty much any SAS/SATA controller will work ok.  You'll be media speed
bound, not I/O channel bound.


I guess my questions are:
- Does anyone out there have a clue where the potential bottlenecks 
might be?


software + cores --> handling the net and managing data integrity.


- Is there anywhere where I can save a bit of money? (For example,
   might the SuperMicro AOC-SAT2-MV8 hanging off the PCI-X slots
   provide enough bandwidth to the disks?)
- If I focused on simple streaming IO, would giving the server less RAM 
have an impact on performance?


RAM as a cache presumes two things: prefetching and data re-use.  Most
likely, you won't have re-use and prefetching only makes sense when the
disk subsystem is approximately the same speed as the network.  Personally,
I'd start at 2-4 GBytes and expand as needed (this is easily measured)

- I had assumed four cores would be better than the two faster (3.0GHz) 
single-core processors the vendor originally suggested. Agree?


Yes, lacking further data.
 -- richard
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS boot: 3 smaller glitches with console, /etc/dfs/sharetab and /dev/random

2007-04-19 Thread Robert Thurlow


Constantin Gonzalez Schmitz wrote:


2. After going through the zfs-bootification, Solaris complains on reboot that
   /etc/dfs/sharetab is missing. Somehow this seems to have been fallen through
   the cracks of the find command. Well, touching /etc/dfs/sharetab just fixes
   the issue.


This is unrelated to ZFS boot issues, and sounds like this bug:

6542481 No sharetab after BFU from snv_55

It's fixed in build 62.

Rob T
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re[2]: [zfs-discuss] Multi-tera, small-file filesystems

Hello Aknin,

Thursday, April 19, 2007, 7:20:26 AM, you wrote:

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, performance, manageability... etc) between a 25TB filesystem with 2^35 files and a 25TB filesystem with 1,000 files, each 25GB?

If you are ok with your application having to access lot of small files then it's not an issue except backup.
Really depends how you want to do your backup. Lot of small files is bad, very bad for classical backup solutions.

In terms of many small files I see no problem with stability, recoverability or performance (depends on app and workload).

Now the difference in a scenario you asked is that if you want to backup 1000 files, depending what file system you use and how you created those files you're probably going to read them mostly sequentially on physical layer. Also it's very cheap in most cases to check 1000 files if they changed instead of millions.

As I wrote - if your app/workload is happy with many small files then fine.
But you'll definitely have a problem with a backup.

Also, if it's possible to ask without stepping out of any of your customers' NDAs, can you at least say what's the average filesize you have on some of your multi-tera volumes (is 10K a small file? is 100K? 1K?)

I'm afraid I can't :(
But I can say that to me anything below 512KB is a small file (starting from few bytes).
Also a file size distribution is such that I have mostly small files and large files, the rest 10% is somewhere between.

--
Best regards,
Robert Milkowski mailto:[EMAIL PROTECTED]
http://milek.blogspot.com

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Re: ZFS disables nfs/server on a host

2007-04-19 Thread Ben Miller

It does seem like an ordering problem, but nfs/server should be starting up 
late enough with SMF dependencies.  I need to see if I can duplicate the 
problem on a test system...
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re[2]: [zfs-discuss] Preferred backup mechanism for ZFS?

Hello Nicolas,

Wednesday, April 18, 2007, 10:12:17 PM, you wrote:

NW> 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 in reason. Like a decade or a century.   But
>> perhaps a backup today will have as much meaning as papertape over
>> time.
>> 
>> 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?

NW> As far as ZFS is concerned any discussion of how you'll read today's
NW> media a decade into the future is completely OT :)

NW> "zfs send" as backup is probably not generally acceptable: you can't
NW> expect to extract a single file out of it (at least not out of an
NW> incremental zfs send), but that's certainly done routinely with ufsdump,
NW> tar, cpio, ...

Depends where you 'zfs send' those data and what you do on the other
side. If you just zfs send <---remote host---> zfs recv
and then also make snapshots you have actually very good backup in
many aspects much better than using tapes.
The only real drawback is management (custom zfs send|recv scripts
compared to Legato, Tivolli, ...).

-- 
Best regards,
 Robertmailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Experience with Promise Tech. arrays/jbod's?

2007-04-19 Thread Marion Hakanson

Greetings,

In looking for inexpensive JBOD and/or RAID solutions to use with ZFS, I've
run across the recent "VTrak" SAS/SATA systems from Promise Technologies,
specifically their E-class and J-class series:

E310f FC-connected RAID:
  http://www.promise.com/product/product_detail_eng.asp?product_id=175

E310s SAS-connected RAID:
  http://www.promise.com/product/product_detail_eng.asp?product_id=176

J300s SAS-connected JBOD:
  http://www.promise.com/product/product_detail_eng.asp?product_id=163


The prices seem very reasonable as compared to Sun, HP, EMC, etc. You can
buy bare drives (SAS or SATA) and plug them into the chassis.  If you're
using dual RAID controllers with SATA drives, they sell a dual-port adapter
that goes in the canister with each disk drive.

Has anyone tried these with Solaris yet?  The docs claim Solaris-ready,
but I'm particularly curious to know if the E310f supports Sun's MPXIO
(multipathing) drivers in the dual-controller configuration.

How about the SAS-connected chassis'?  What SAS HBA's are people using
with Solaris-10?

I'm mostly hoping to hear if these products are decent, or junk, or somewhere
in between.

Thanks and regards,

Marion


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Preferred backup mechanism for ZFS?

2007-04-19 Thread Manoj Joseph


Dennis Clarke wrote:

So now here we are ten years later with a new filesystem and I have no
way to back it up in such a fashion that I can restore it perfectly. I
can take snapshots. I can do a strange send and receive but the
process is not stable From zfs (1M) we see :

The format of the stream is evolving. No backwards  compati-
bility  is  guaranteed.  You may not be able to receive your
streams on future versions of ZFS.


The format of the stream may not be stable. So you can't dump the stream 
to a file somewhere and expect to receive from it sometime in the future.


But if you stash it away as a pool on the same machine or elsewhere, it 
is not an issue.


# zfs send [-i b] pool/[EMAIL PROTECTED] | [ssh host] zfs receive 
poolB/received/[EMAIL PROTECTED]

Right? I think this is quite cool! :)

-Manoj
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Permanently removing vdevs from a pool

2007-04-19 Thread Mario Goebbels

Is it possible to gracefully and permanently remove a vdev from a pool without 
data loss? The type of pool in question here is a simple pool without 
redundancies (i.e. JBOD). The documentation mentions for instance offlining, 
but without going into the end results of doing that. The thing I'm looking for 
is an option to evacuate, for the lack of a better word, the data from a 
specific vdevs to the other vdevs in the pool, so the device can simply be 
removed.

Scenarios for this would be inavailability of spares (this actually happened to 
me, in a fairly huge computer wholesales none the less (sad chapter)) and disk 
replacements in an end user scenario.

Thanks.
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Permanently removing vdevs from a pool

2007-04-19 Thread Mark J Musante

On Thu, 19 Apr 2007, Mario Goebbels wrote:

> Is it possible to gracefully and permanently remove a vdev from a pool
> without data loss?

Is this what you're looking for?
http://bugs.opensolaris.org/view_bug.do?bug_id=4852783

If so, the answer is 'not yet'.

Regards,
markm
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Permanently removing vdevs from a pool

2007-04-19 Thread Matty

On 4/19/07, Mark J Musante <[EMAIL PROTECTED]> wrote:

On Thu, 19 Apr 2007, Mario Goebbels wrote:

> Is it possible to gracefully and permanently remove a vdev from a pool
> without data loss?

Is this what you're looking for?
http://bugs.opensolaris.org/view_bug.do?bug_id=4852783

If so, the answer is 'not yet'.

Can the ZFS team comment on how far out this feature is? There are a
couple of items 9and bugs) that are preventing us from deploying ZFS,
and this is one of them.

Thanks for any insight,
- Ryan
--
UNIX Administrator
http://prefetch.net
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Permanently removing vdevs from a pool

2007-04-19 Thread Bill Sommerfeld

On Thu, 2007-04-19 at 11:59 -0700, Mario Goebbels wrote:
> Is it possible to gracefully and permanently remove a vdev from a pool
> without data loss? 

Not yet.  But it's on lots of people's wishlists, there's an open RFE,
and members of the zfs team have said on this list that they're working
on it..

Bugid is:

4852783 reduce pool capacity

- Bill

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Re: Testing of UFS, VxFS and ZFS

2007-04-19 Thread Tony Galway

To give you fine people an update, it seems that the reason for the skewed 
results shown earlier is due to Veritas' ability to take advantage of all the 
free memory available on my server. My test system has 32G of Ram, and my test 
data file is 10G. Basically, Veritas was able to cache the entire data file. 


On the suggestion that I use a larger data file, I have increased the file to 
100G and have re-run my Veritas tests with an 8k File Block and 8k Request 
Block size. In doing this, I have run into a different issue, which I have now 
resolved. That being - my server became fully unresponsive during testing! 
Basically, Veritas allowed itself to consume all the memory of my server, all 
32G, and then when it had used all of its memory, it looked for more and hung 
the server due to resource contention. To alleviate this problem, I tuned the 
Veritas file system using the write_throttle tunable. I first set this to be 
99.5% of my Ram,  then 50% and now I am running at about 256Mb (32651 pages). 

 
The reason I had decreased the values down to the current (32651) page size is 
that, while the server would be responsive, my test volume would not be so. It 
took 35 minutes for the paging to stop when I had set the write_throttle to 50% 
of Ram, and only after that paging completed did the test resume. At the 
current value, the test will continue for a period, then flush, continue, etc. 

 
Given my current configuration, I now see an IO rate of 756 versus my prior 
27,329!!!

 
I am continuing my testing, and will re-test UFS and ZFS with the larger file 
size as well to properly discover the differences. Also, in subsequent testing, 
I will also test with a full un-buffered Veritas & UFS volume to compare with 
ZFS, which may be a more reasonable test due to ZFS's copy-on-write 
architecture.


I will send out the full results when they are compiled.
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Permanently removing vdevs from a pool

2007-04-19 Thread Cindy . Swearingen


Mario,

Until zpool remove is available, you don't have any options to remove a
disk from a non-redundant pool.

Currently, you can:

- replace or detach a disk in a ZFS mirrored storage pool
- replace a disk in a ZFS RAID-Z storage pool

Please see the ZFS best practices site for more info about using
redundant ZFS configurations:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide

Cindy

Mario Goebbels wrote:

Is it possible to gracefully and permanently remove a vdev from a pool without 
data loss? The type of pool in question here is a simple pool without 
redundancies (i.e. JBOD). The documentation mentions for instance offlining, 
but without going into the end results of doing that. The thing I'm looking for 
is an option to evacuate, for the lack of a better word, the data from a 
specific vdevs to the other vdevs in the pool, so the device can simply be 
removed.

Scenarios for this would be inavailability of spares (this actually happened to 
me, in a fairly huge computer wholesales none the less (sad chapter)) and disk 
replacements in an end user scenario.

Thanks.
 
 
This message posted from opensolaris.org

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Re: zfs boot image conversion kit is posted

2007-04-19 Thread Lori Alt


I was hoping that someone more well-versed in virtual machines
would respond to this so I wouldn't have to show my ignorance,
but no such luck, so here goes:

Is it even possible to build a virtual machine out of a
zfs storage pool?  Note that it isn't just zfs as a root file system
we're trying out.  It's the whole concept of booting from
a dataset within a storage pool.   I don't know enough about
how one sets up a virtual machine to know whether it's
possible or even meaningful to talk about generating a
b62-on-zfs virtual machine.

Lori

MC wrote:


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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
 



___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?


Marion Hakanson wrote:

In looking for inexpensive JBOD and/or RAID solutions to use with ZFS, I've
run across the recent "VTrak" SAS/SATA systems from Promise Technologies,
specifically their E-class and J-class series:

E310f FC-connected RAID:
  http://www.promise.com/product/product_detail_eng.asp?product_id=175

E310s SAS-connected RAID:
  http://www.promise.com/product/product_detail_eng.asp?product_id=176

J300s SAS-connected JBOD:
  http://www.promise.com/product/product_detail_eng.asp?product_id=163


The prices seem very reasonable as compared to Sun, HP, EMC, etc. You can
buy bare drives (SAS or SATA) and plug them into the chassis.  If you're
using dual RAID controllers with SATA drives, they sell a dual-port adapter
that goes in the canister with each disk drive.

Has anyone tried these with Solaris yet?  The docs claim Solaris-ready,
but I'm particularly curious to know if the E310f supports Sun's MPXIO
(multipathing) drivers in the dual-controller configuration.


This looks similar to the recently announced Sun StorageTek 2500 Low Cost
Array product line.
http://www.sun.com/storagetek/disk_systems/workgroup/2500/

multi-path support is coming later (sorry, I don't know the details)


How about the SAS-connected chassis'?  What SAS HBA's are people using
with Solaris-10?


http://www.sun.com/storagetek/storage_networking/hba/sas/specs.xml
 -- richard
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] LZO compression?

2007-04-19 Thread Ricardo Correia

Forwarding some simple benchmarks, just to peek your curiosity.
Very interesting results.

 Original Message 
Subject: [zfs-fuse] probably some better numbers ;)
Date: Thu, 19 Apr 2007 22:07:31 +0200
From: roland <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>


linux kernel source, (239M)

time tar xf linux-2.6.20.3.tar

|compression  |time-real  |time-user |time-sys  |compressratio
--
|lzo  |6m39.603s  |0m1.288s  |0m6.055s  |2.99x
|gzip |7m46.875s  |0m1.275s  |0m6.312s  |3.41x
|lzjb |7m7.600s   |0m1.227s  |0m6.033s  |1.79x
|off  |7m26.735s  |0m1.348s  |0m6.230s  |1.00x

this test was done an an ancient suse 9.1 box, fuse 2.5.3, 1,25 GB RAM
(1 gb
in use for other apps), 2x80gb 3ware raid1

first (vague) conclusion:
gzip compresses best, lzo is fastest and it seems that fuse (or
whatever) is
the real bottleneck - at least not cpu or i/o

after waiting for so long - 2 additional compression schemes for zfs - in
one day!

thanks ricardo and thanks eric for making this !

so, now someone willing to implement bzip2 compression ?
:D

regards
roland

ps:
maybe someone likes to test this on a newer system? i have no suiteable
around here for now - maybe later.


- Original Message -
From: Eric Dillmann
To: zfs-fuse
Sent: Thursday, April 19, 2007 12:05 PM
Subject: [zfs-fuse] Some numbers


tar cf - zfs-fuse | (cd /wd1/test-lzo/;time tar xf -)
0.07user 0.32system 0:07.97elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+306minor)pagefaults 0swaps

tar cf - zfs-fuse | (cd /wd1/test-lzjb/;time tar xf -)
0.08user 0.45system 0:09.97elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+306minor)pagefaults 0swaps

tar cf - zfs-fuse | (cd /wd1/test-gzip/;time tar xf -)
0.08user 0.41system 0:13.80elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+305minor)pagefaults 0swaps

zfs get compressratio
wd1/test-gzipcompressratio
-
wd1/test-lzo compressratio
-
wd1/test-lzjbcompressratio
   -

Regards,
Eric

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] LZO compression?

2007-04-19 Thread Ricardo Correia

Ricardo Correia wrote:
> |compression  |time-real  |time-user |time-sys  |compressratio
> --
> |lzo  |6m39.603s  |0m1.288s  |0m6.055s  |2.99x
> |gzip |7m46.875s  |0m1.275s  |0m6.312s  |3.41x
> |lzjb |7m7.600s   |0m1.227s  |0m6.033s  |1.79x
> |off  |7m26.735s  |0m1.348s  |0m6.230s  |1.00x

BTW, those time-sys numbers do not have any real meaning since in
zfs-fuse the ZFS code runs under the context of another process.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Re: LZO compression?

2007-04-19 Thread roland

please be cautious with this benchmarks and don`t make early decisions based on 
this.
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re[2]: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?

Hello Richard,

Thursday, April 19, 2007, 10:41:58 PM, you wrote:

RE> Marion Hakanson wrote:
>> In looking for inexpensive JBOD and/or RAID solutions to use with ZFS, I've
>> run across the recent "VTrak" SAS/SATA systems from Promise Technologies,
>> specifically their E-class and J-class series:
>> 
>> E310f FC-connected RAID:
>>   http://www.promise.com/product/product_detail_eng.asp?product_id=175
>> 
>> E310s SAS-connected RAID:
>>   http://www.promise.com/product/product_detail_eng.asp?product_id=176
>> 
>> J300s SAS-connected JBOD:
>>   http://www.promise.com/product/product_detail_eng.asp?product_id=163
>> 
>> 
>> The prices seem very reasonable as compared to Sun, HP, EMC, etc. You can
>> buy bare drives (SAS or SATA) and plug them into the chassis.  If you're
>> using dual RAID controllers with SATA drives, they sell a dual-port adapter
>> that goes in the canister with each disk drive.
>> 
>> Has anyone tried these with Solaris yet?  The docs claim Solaris-ready,
>> but I'm particularly curious to know if the E310f supports Sun's MPXIO
>> (multipathing) drivers in the dual-controller configuration.

RE> This looks similar to the recently announced Sun StorageTek 2500 Low Cost
RE> Array product line.
RE> http://www.sun.com/storagetek/disk_systems/workgroup/2500/

RE> multi-path support is coming later (sorry, I don't know the details)

MPxIO for SAS went into b63 - see 
http://www.opensolaris.org/os/community/on/flag-days/pages/2007041203/

Now the question is if it will make s10u4?

-- 
Best regards,
 Robertmailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?


Robert Milkowski wrote:

RE> This looks similar to the recently announced Sun StorageTek 2500 Low Cost
RE> Array product line.
RE> http://www.sun.com/storagetek/disk_systems/workgroup/2500/

RE> multi-path support is coming later (sorry, I don't know the details)

MPxIO for SAS went into b63 - see 
http://www.opensolaris.org/os/community/on/flag-days/pages/2007041203/


Nice catch... timing is everything :-)
I'll infer from this that the SAS HBA from Sun is based on the mpt driver which
works with LSI controllers.
 -- richard
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?


Robert Milkowski wrote:
...


RE> multi-path support is coming later (sorry, I don't know the details)

MPxIO for SAS went into b63 - see 
http://www.opensolaris.org/os/community/on/flag-days/pages/2007041203/

Now the question is if it will make s10u4?


We're working on that right now. The backport has been
assigned to me and we're hoping to get patches out
real soon now. No committment on actual dates though.



James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?


Richard Elling wrote:
...

Nice catch... timing is everything :-)
I'll infer from this that the SAS HBA from Sun is based on the mpt 
driver which works with LSI controllers.


yes.


James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re[2]: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?

Hello James,

Friday, April 20, 2007, 12:53:04 AM, you wrote:

JCM> Robert Milkowski wrote:
JCM> ...

>> RE> multi-path support is coming later (sorry, I don't know the details)
>> 
>> MPxIO for SAS went into b63 - see 
>> http://www.opensolaris.org/os/community/on/flag-days/pages/2007041203/
>> 
>> Now the question is if it will make s10u4?

JCM> We're working on that right now. The backport has been
JCM> assigned to me and we're hoping to get patches out
JCM> real soon now. No committment on actual dates though.

Thanks.

-- 
Best regards,
 Robertmailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?

2007-04-19 Thread Marion Hakanson

[EMAIL PROTECTED] said:
> This looks similar to the recently announced Sun StorageTek 2500 Low Cost
> Array product line. http://www.sun.com/storagetek/disk_systems/workgroup/2500/

Wonder how I missed those.  Oh, probably because you can't see them
on store.sun.com/shop.sun.com.  On papger, there are some differences
between this product and the VTrak E310f:
  - VTrak has RAID-6;  ST-2500 does not.
  - VTrak can take SATA disks;  ST-2500 lists only 15k rpm SAS disks.
  - VTrak can take up to 4 expansion shelves;  ST-2500 takes only 2.
  - VTrak has 3-yr advance-return warranty;  ST-2500 has 1-yr on-site.

Thanks for the SAS HBA and SAS MPXIO information.  Now, anyone have any
experience with the VTrak E-series arrays?  Does it work with Sun's
fiber channel MPXIO drivers?

Regards,

Marion


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?


Marion Hakanson wrote:

[EMAIL PROTECTED] said:

This looks similar to the recently announced Sun StorageTek 2500 Low Cost
Array product line. http://www.sun.com/storagetek/disk_systems/workgroup/2500/


Wonder how I missed those.  Oh, probably because you can't see them
on store.sun.com/shop.sun.com.  On papger, there are some differences
between this product and the VTrak E310f:
  - VTrak has RAID-6;  ST-2500 does not.


that's not necesarily a bad thing. "raid-6" is an interpretable feature,
not one that different vendors agree on a definition for.


  - VTrak can take SATA disks;  ST-2500 lists only 15k rpm SAS disks.


I think that might be a different model.

...

Thanks for the SAS HBA and SAS MPXIO information.  Now, anyone have any
experience with the VTrak E-series arrays?  Does it work with Sun's
fiber channel MPXIO drivers?


The scsi_vhci multipathing driver doesn't just work with Sun's
FC stack, it also works with SAS (at least, it does in snv_63
and ... soon .. with patches for s10).

Multipathing support tends to depend on table entries and
manufacturer-specific information if the array isn't active/active.
So ... unless the VTrak array is active/active in your configuration,
then you probably won't see any multipathing capabilities. If you
want them added you should log an RFE requesting that support
be added.


cheers,
James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?

2007-04-19 Thread Marion Hakanson

[EMAIL PROTECTED] said:
> The scsi_vhci multipathing driver doesn't just work with Sun's FC stack, it
> also works with SAS (at least, it does in snv_63 and ... soon .. with patches
> for s10). 

Yes, it's nice to see that's coming;  And that FC & SAS are "the same".
But I'm at S10U3 right now.


> Multipathing support tends to depend on table entries and manufacturer-specifi
> c information if the array isn't active/active. So ... unless the VTrak array
> is active/active in your configuration, then you probably won't see any
> multipathing capabilities. If you want them added you should log an RFE
> requesting that support be added. 

I have experience making S10 MPXIO work with 3rd-party arrays (HDS);  This
VTrak model can be configured to do active/active in a mode which looks
like what Sun calls "symmetric".  But my experience tells me that mileage
may vary.  As I haven't bought anything yet, I was hoping to hear from
someone who has already tried it.


> >   - VTrak can take SATA disks;  ST-2500 lists only 15k rpm SAS disks.
> I think that might be a different model.

Understood.  Perhaps I'm odd, but the fact that the same VTrak model can
take either SAS or SATA disks, depending on needs, is a good feature.  Our
customers are researchers, and such flexibility is a plus.  Too bad it's
so hard to get pricing on the ST-2500 unit.  Here's one reference I found
which gives a idea:
http://www.storageperformance.org/results/b00022_Sun-ST2540-Mirroring_SPC2_full
-disclosure.pdf

Thanks for the note,

Marion


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Re: zfs boot image conversion kit is posted

2007-04-19 Thread Jim Mauro



I'm not sure I understand the question.
Virtual machines are built by either running a virtualization technology
in a host operating systems, such as running VMware Workstation in
Linux, running Parallels in Mac OS X, Linux or Windows, etc.
These are sometimes referred to as Type II VMMs, where the
VMM (Virtual Machine Monitor - the chunk of software responsible
for running the guest operating system) is hosted by a traditional
operating system.

In Type I VMMs, the VMM runs on the hardware. VMware ESX
Server is an example of this (although some argue it is not, since
technically there's an ESX kernel that runs on the hardware in
support of the VMM). So

Building a virtual machine on a zpool would require that the host
operating system supports ZFS. An example here would be our
forthcoming (no, I do not know when), Solaris/Xen integration,
assuming there is support for putting Xen domU's on a ZFS.

It may help to point out that when a virtual machine is created,
it includes defining a virtual hard drive, which is typically just a
file in the file system space of the hosting operating system.
Given that, a hosting operating system that supports ZFS can allow
for configuring virtual hard drives in the ZFS space.

So I guess the anwer to your question is theoretically yes, but I'm
not aware of an implementation that would allow for such a
configuration that exists today.

I think I just confused the issue...ah well...

/jim

PS - FWIW, I have a zpool configured in nv62 running in a Parallels
virtual machine on Mac OS X. The nv62 "system disk" is a virtual
hard disk that exists as a file in Mac OS X HFS+, thus this particular
zpool is a partition on that virtual hard drive.



Lori Alt wrote:

I was hoping that someone more well-versed in virtual machines
would respond to this so I wouldn't have to show my ignorance,
but no such luck, so here goes:

Is it even possible to build a virtual machine out of a
zfs storage pool?  Note that it isn't just zfs as a root file system
we're trying out.  It's the whole concept of booting from
a dataset within a storage pool.   I don't know enough about
how one sets up a virtual machine to know whether it's
possible or even meaningful to talk about generating a
b62-on-zfs virtual machine.

Lori

MC wrote:

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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
 



___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?

2007-04-19 Thread James W. Abendschan

On Fri, 20 Apr 2007, James C. McPherson wrote:

> Richard Elling wrote:
> ...
> > Nice catch... timing is everything :-)
> > I'll infer from this that the SAS HBA from Sun is based on the mpt
> > driver which works with LSI controllers.
>
> yes.

As of Solaris 10 update 2, this combo did -not- work:

 - Sun T1000
 - Promise vtrak J300s (12 SATA drives presented as SAS)
 - LSI SAS3442E-R

See http://groups.google.com/group/comp.unix.solaris/msg/c8ad66278a5bf817
for more info.

I would be -delighted- to find that this is no longer the case.
After failing to get anywhere with the above setup, we punted and
went with Linux... which is better than what it replaced, but
I'd much rather be using ZFS than XFS or ext3!

The J300s itself isn't too bad.  We have 24 of them and they've
been in service for the past 6 months w/o problems; two of them
were DOA though and had to be RMA'd.  We had (and are still having)
a very hard time getting rails for them, so keep that in mind.

James

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?


James W. Abendschan wrote:

On Fri, 20 Apr 2007, James C. McPherson wrote:


Richard Elling wrote:
...

Nice catch... timing is everything :-)
I'll infer from this that the SAS HBA from Sun is based on the mpt
driver which works with LSI controllers.

yes.


As of Solaris 10 update 2, this combo did -not- work:

 - Sun T1000
 - Promise vtrak J300s (12 SATA drives presented as SAS)
 - LSI SAS3442E-R

See http://groups.google.com/group/comp.unix.solaris/msg/c8ad66278a5bf817
for more info.

I would be -delighted- to find that this is no longer the case.
After failing to get anywhere with the above setup, we punted and
went with Linux... which is better than what it replaced, but
I'd much rather be using ZFS than XFS or ext3!

The J300s itself isn't too bad.  We have 24 of them and they've
been in service for the past 6 months w/o problems; two of them
were DOA though and had to be RMA'd.  We had (and are still having)
a very hard time getting rails for them, so keep that in mind.


Hi James,
thankyou for the pointer to that newsgroup article.

Since s10u2 we've fixed numerous issues with the mpt
driver on both Sparc and x86/x64. For instance, in
the latest version (125037-02 sparc / 125038-02 x86)
these items are addressed:


6368089 mpt misinterprets integrated raid events with reason code 
VOLUME_STATUS_CHANGED

6408660 mpt/scsi panicked due to general protection fault
6418521 sd driver with Solaris 10, LSI 1064 SAS HBA can't detect more than 
12 drives
6457857 x86 showing mpt0: unknown event e received running bonnie/dbench on 
HW raid



If you have the opportunity to try out s10u3 + the
appropriate mpt patch I hope you'd see much better
behaviour.


cheers,
James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Re: zfs boot image conversion kit is posted

2007-04-19 Thread Brian Hechinger

On Thu, Apr 19, 2007 at 08:55:24PM -0400, Jim Mauro wrote:
> 
> Server is an example of this (although some argue it is not, since
> technically there's an ESX kernel that runs on the hardware in
> support of the VMM). So

And that kernel is linux, so..  ;)

> Building a virtual machine on a zpool would require that the host
> operating system supports ZFS. An example here would be our

This is not true.  See below.

> It may help to point out that when a virtual machine is created,
> it includes defining a virtual hard drive, which is typically just a
> file in the file system space of the hosting operating system.
> Given that, a hosting operating system that supports ZFS can allow
> for configuring virtual hard drives in the ZFS space.

Again, this is not true, the "host" OS (the OS running VMWare or
whatnot) doesn't need to know anything at all about what filesystem
the "guest" OS (the OS you are installing into the virtual machine) uses.

The virtualization software takes that file you mention and makes it
appear to be a physical device to the guest OS, so the guest OS is
none the wiser.  The host OS just has a file (or sometimes that file
is split into smaller chunks) that contains the guest OS's pretend
hard-drive.

There is no reason why zfsroot/boot shouldn't work in a VM any more
than any other OS/FS combo wouldn't.

I run Solaris in VMs all the time, a lot of times with ZFS pools, and
it works great.

I will setup a VM image that can be downloaded (I hope to get it done
tomorrow, but if not definitely by early next week) and played with
by anyone who is interested.

-brian
-- 
"Perl can be fast and elegant as much as J2EE can be fast and elegant.
In the hands of a skilled artisan, it can and does happen; it's just
that most of the shit out there is built by people who'd be better
suited to making sure that my burger is cooked thoroughly."  -- Jonathan 
Patschke
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re[2]: [zfs-discuss] Re: zfs boot image conversion kit is posted

Hello Brian,

Friday, April 20, 2007, 3:20:03 AM, you wrote:

BH> On Thu, Apr 19, 2007 at 08:55:24PM -0400, Jim Mauro wrote:

>> Building a virtual machine on a zpool would require that the host
>> operating system supports ZFS. An example here would be our

BH> This is not true.  See below.

>> It may help to point out that when a virtual machine is created,
>> it includes defining a virtual hard drive, which is typically just a
>> file in the file system space of the hosting operating system.
>> Given that, a hosting operating system that supports ZFS can allow
>> for configuring virtual hard drives in the ZFS space.

BH> Again, this is not true, the "host" OS (the OS running VMWare or
BH> whatnot) doesn't need to know anything at all about what filesystem
BH> the "guest" OS (the OS you are installing into the virtual machine) uses.

I think you misunderstood Jim and you're both right.

One case is running virtual machine on a zfs, and another one is using
zfs inside a virtual machine. Those are two different things.

Running virtual machines on a host os with ZFS has several
advantages when you consider all benefits coming from snapshots,
clones and possibly thin zvol provisioning. Not to mention
checksuming which is even more important with virtual machines as
potential data corruption in host os could affect many virtual
systems.

Now the original question by MC I belive was about providing
VMware and/or Xen image with guest OS being snv_62 with / as zfs.
This should allow people to just download such image and run snv_62
with zfs as rootfs without all the hassle there's right now to set it
up.

-- 
Best regards,
 Robert Milkowski  mailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Re: Cheap Array Enclosure for ZFS pool?

2007-04-19 Thread Chris Greer

We've used enclosures manufactured by Xyratex (http://www.xyratex.com/).  
Several RAID vendors have used these disk in their systems.  One reseller is 
listed below (the one we used got bought out).  I've been very happy with these 
enclosures and a Qlogic HBA.

As we have retired some of the RAID arrays I'm redeploying the drives in ZFS 
pools.
We have the fiber channel and the SATA versions of their enclosure and both 
work well.


http://pacdata.com/index.php?page=766437.txt
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Preferred backup mechanism for ZFS?

2007-04-19 Thread Wee Yeh Tan


Hi Tim,

I  run a setup of SAM-FS for our main file server and we loved the
backup/restore parts that you described.

The main concerns I have with SAM fronting the entire conversation is
data integrity. Unlike ZFS, SAMFS does not do end to end checksumming.

We have considered the setup you proposed (samfs copy1 -> ZFS) but you
will run into problem with fs-cache.  Being only a copy, ZFS probably
do not need much caching but will win the battle for memory due to the
way its cache is managed.  Unless there is a visible memory shortfall,
ZFS will starve (sorry guys) samfs from memory it could use as cache.
Also, ZFS's data integrity feature is limited by the use of 2nd hand
data.


--
Just me,
Wire


On 4/19/07, Tim Thomas <[EMAIL PROTECTED]> wrote:

Hi Robert

no, SAM-FS does not work with ZFS, it is still tied to QFS i.e. the SAM
piece cannot archive data straight out of a ZFS file system.

I am a big fan of SAM-FS so forgive me if I expand a little on the topic...

The way a solution like this would work is that you would build a SAM-FS
file system on some of the disks and a ZFS file system on some others.
Maybe SAM-FS would be on "fast" disks and ZFS on "slow" disks.

Your application would write files into the SAM-FS file system. In my
work this application would be an archiving application that has
extracted data (e.g emails) out of a business application and now wants
somewhere to put the archived data.

SAM-FS can then make copies of the files (back them up) in to the ZFS
file system and to tape (at the same or another time) up to a maximum of
4 copies...so from SAM-FS's perspective ZFS is being treated as a disk
archiveSAM-FS does not care that it writing to a ZFS file system
..it just sees a directory that it can treat as a target to make backup
copies of data into. ZFS is nice here because it can be used with JBODs
and can do software RAID.

SAM-FS (and it's little brother QFS which is the file system without the
archiving), both do software RAID, but only RAID-0...so the underlying
"disks" need to be h/ware RAID protected or logical volumes built with
something like Solaris Volume Manager.

So (you may ask) why would anyone want to do this ? Well...think of the
SAM-FS file system as a cache...once it has backed up a file to a disk
and/or tape archive it can be configured to "release" the file's data
blocks and just leave a stub behind. The file is now viewed as off-line
(Hey, this looks like HSM!) - There are a rich set of rules you can
define around when this happens - the simplest is to do it when the file
system passes a high %full watermark...in short..IT NEVER FILLS UP!

So that is pretty cool...so here is the next really nice bit, the files
are backed up continuously (once again. there are a rich set of rules
around this)...no huge backup windows while millions of small files are
backed up like a conventional backup product...SAM-FS will back them up
throughout the day...also, NO  INCREMENTAL BACKUPS required...we are
working at a per file level here. If a  file is written and never
changes SAM-FS will make copies of it and then we are done..we never
copy it again unless it changes...there is just one image of the file
system.

SAM-FS handles all the interaction with tape libraries etc...no extra
s/ware required.

So, what if you open a released file ? Once you read past the end of the
stub SAM-FS stages the rest of the data back from archivesit is
transparent...and it really is...if the file is having to come back from
tape the long delays can cause application issues sometimes but files
coming back from disk archives come back so fast that there are no problems.

You can access SAM-FS via NFS and CIFS/SAMBA safely. NFS client need to
support correct handling of the NFS EJUKEBOX error code...Solaris's does.

Now, what if you loose a whole file system with millions of files in it.
Recovering that from backups is no fun. part of managing SAM-FS is
taking regular backups of the metadata...this is effectively a snapshot.
If a  file system is lost due to catastrophic h/ware failure then you
can restore the meta into an empty SAM-FS file system (which can be
smaller or larger than the original) in a  few minutes and bingo, all
the data is there again..with all the files off-line.

SAM-FS management is all via the command line or via a really nice Web
based UI. I won't pretend that it is as easy as ZFS to create a SAM-FS
file system 'cause it aint'..but heck, it's fun once you get with
it...and the GUI certainly makes life much easier.

So..what is the "bad" stuff, other than no RAID-Z equivalent, well: you
cannot grow a SAM-FS file system on-line..it needs to be unmounted
first; No snapshots (other than the meta data based ones); you have to
back up the meta data regularly as that is effectively the backup
catalog which can be a drag but the procedures are well defined.

There is other stuff that SAM-FS can do such as shared Global File
system support in SAN

Re: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?

2007-04-19 Thread Frank Cusack

On April 19, 2007 4:45:20 PM -0700 Marion Hakanson <[EMAIL PROTECTED]> 
wrote:

  - VTrak can take SATA disks;  ST-2500 lists only 15k rpm SAS disks.


I'd be surprised (and disappointed) if the 2500 can't accept a SATA disk.


Thanks for the SAS HBA and SAS MPXIO information.  Now, anyone have any
experience with the VTrak E-series arrays?  Does it work with Sun's
fiber channel MPXIO drivers?


Isn't MPXIO support by HBA and hard drive identification (not by the
enclosure)?  At least I don't see how the enclosure should matter, as
long as it has 2 active paths.  So if you add the drive vendor info
into /kernel/drv/scsi_vhci.conf it should work.

-frank
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re[2]: [zfs-discuss] Experience with Promise Tech. arrays/jbod's?

Hello Frank,

Friday, April 20, 2007, 4:50:07 AM, you wrote:

FC> On April 19, 2007 4:45:20 PM -0700 Marion Hakanson <[EMAIL PROTECTED]>
FC> wrote:
>>   - VTrak can take SATA disks;  ST-2500 lists only 15k rpm SAS disks.

FC> I'd be surprised (and disappointed) if the 2500 can't accept a SATA disk.

>> Thanks for the SAS HBA and SAS MPXIO information.  Now, anyone have any
>> experience with the VTrak E-series arrays?  Does it work with Sun's
>> fiber channel MPXIO drivers?

FC> Isn't MPXIO support by HBA and hard drive identification (not by the
FC> enclosure)?  At least I don't see how the enclosure should matter, as
FC> long as it has 2 active paths.  So if you add the drive vendor info
FC> into /kernel/drv/scsi_vhci.conf it should work.

In a so called symmetric mode it should work as you described.
But many entry level and midsize arrays aren't actually symmetric and
they have to be treated specifically.

And when it comes to SAS - Solaris mpt driver didn't work with MPxIO
prior to b63.

-- 
Best regards,
 Robertmailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re[2]: [zfs-discuss] Preferred backup mechanism for ZFS?