Re: [zfs-discuss] [ldoms-discuss] Solaris 10 patch 137137-09 broke LDOM
another update - instead of net booting to recovery i tried adding the iso to
the primary ldom and adding it to the ldom to run installboot again from a S10
U6 dvd iso. I have return to my first error message:
{0} ok boot /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] -s
SPARC Enterprise T2000, No Keyboard
Copyright 2008 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.29.0.a, 6144 MB memory available, Serial #66845120.
Ethernet address 0:14:4f:fb:f9:c0, Host ID: 83fbf9c0.
Boot device: /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] File and
args: -s
|
Warning: Fcode sequence resulted in a net stack depth change of 1
The file just loaded does not appear to be executable.
other information i am using ldom 1.0.3
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Mirror and RaidZ on only 3 disks
Hi, I have a small Linux server PC at home (Intel Core2 Q9300, 4 GB RAM), and I'm seriously considering switching to OpenSolaris (Indiana, 2008.11) in the near future, mainly because of ZFS. The idea is to run the existing CentOS 4.7 system inside a VM and let it NFS mount home directories and other filesystems from OpenSolaris. I might migrate more services from Linux over time, but for now, the filesystems are priority one. Since most of my questions are actually about ZFS, I thought I'd ask here directly. First of all, I'm on a budget and while "cheap" is important, "value for the money" is critical. So the less number of disk, the better (not only because of price but also because of power consumption and the lack of cooling). This also means that I prefer RAID-Z to mirrors for less critical data. 1) My plan is to install 2008.11 on three 1 TB disks (Samsung SpinPoint F1, two new and one currently containing Linux data). I will start with a single, new disk and install the OS on a zpool inside an fdisk partition, say 100 GB large. This is where the OS and /home will live. The rest of the disk will later be used for less critical data (music, video, VMs, backups, etc), inside an fdisk partition of type "Unix". Once installed, I'll attach the second new disk, using identical partition layout, and attach the 100 GB partition as mirror to the root pool. I'll then create a sparse ZFS volume and use this together with the unused fdisk partition on each disk to create a 3-way RAID-Z pool, and finally degrade it by taking the sparse file offline. I'll then start migrating the Linux files, probably using a VM directly mounting the ext3 filesystems from the old 1 TB disk and copying home directories to the mirror pool and media files to the raid-z pool. Finally, I'll reformat and attach the third disk to the pools. I thus hope to end up with three disk and two pools: one small 3-way mirror for critical data and one large 3-way raid-z pool for the rest. How does this idea sound to you? Will I be able to enable the write cache in this setup (not that write speed matters much to me, but still)? 2) Given the perhaps unusual disk layout, do you think I'll run into trouble concerning OS upgrades or if/when one of the disks fails? I've tried the procedure in VMware and found a few gotchas, but nothing too serious (like "zpool import -f rpool" to make grub work after installation, and trying to create the second zpool on c4t0d0p1 -- which happened to be the same as c4t0d0s0, where rpool lives -- instead of c4t0d0p2; funny "zpool create" didn't complain?) 3) One problem I don't understand why I got is this: When I attach a new virgin disk to the system, I first run format->fdisk to make two fdisk partitions and then use prtvtoc/fmthard to create the splices on the solaris partition. When I then try to attach the new c4t1d0s0 to the existing c4t1d0s0, zpool complains that only complete disks can be attached. However, after a reboot, the slice attaches without problems (except that I have to use -f since c4t1d0s0 overlaps with c4t1d0s2, which is also something I don't understand -- of course it does?). How come? 4) I plan to use a sparse ZFS volume for the Linux VM root disk, probably from the mirror pool. Objections? 5) Given that this is all cheap PC hardware ... can I move a disk from a broken controller to another, and if so, how? I tried this in VMware, but could not figure out how to re-attach the moved disk. zpool complains that the moved disk is part of an active zpool and -f didn't help at all. Any input would be greatly appreciated! -- Martin Blom --- [EMAIL PROTECTED] Eccl 1:18 http://martin.blom.org/ smime.p7s Description: S/MIME Cryptographic Signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [ldoms-discuss] Solaris 10 patch 137137-09 broke LDOM
Sorry this is the rest of my problem... Hi, I just finished patching 30+ LDoms and on the last one I get this error when booting. - - SPARC Enterprise T2000, No Keyboard Copyright 2008 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.29.0.a, 6144 MB memory available, Serial #66845120. Ethernet address 0:14:4f:fb:f9:c0, Host ID: 83fbf9c0. Boot device: /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]:a File and args: seek failed Warning: Fcode sequence resulted in a net stack depth change of 1 Evaluating: Evaluating: The file just loaded does not appear to be executable. < br /> I have a number of T2000 servers all with the same firmware and OS patch level. sc> showsc version -v Advanced Lights Out Manager CMT v1.6.5 SC Firmware version: CMT 1.6.5 SC Bootmon version: CMT 1.6.5 VBSC 1.6.7.b VBSC firmware built Sep 29 2008, 09:30:31 SC Bootmon Build Release: 01 SC bootmon checksum: E6213179 SC Bootmon built Sep 29 2008, 08:37:29 SC Build Release: 01 SC firmware checksum: EA9D0B0D SC firmware built Sep 29 2008, 09:34:34 SC firmware flashupdate FRI NOV 07 04:20:00 2008 SC System Memory Size: 32 MB SC NVRAM Version = 14 SC hardware type: 4 FPGA Version: 4.2.4.7 sc> showhost SPARC-Enterprise-T2000 System Firmware 6.6.7 2008/09/29 09:36 Host flash versions: OBP 4.29.0.a 2008/09/15 12:01 Hypervisor 1.6.7.a 2008/09/29 09:29 POST 4.29.0.a 2008/09/15 12:26 ### And my LDOMs all have the same OS patch level as well, the only thing different on this one that i am getting this error it has Sun Studio 12 + studios patches. The LDOM has UFS boot file system and ZFS pools for my Global Zone. The system was built of Solaris 10 U5. I tried installboot recovery from U5 but that didn't work and U6 i get another error when boot over net: Requesting Internet Address for 0:14:4f:f9:84:f3 boot: cannot open kernel/sparcv9/unix Enter filename [kernel/sparcv9/unix] Help needed. Any ideas? Thanks, James -- 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] [ldoms-discuss] Solaris 10 patch 137137-09 broke LDOM
I've tried using S10 U6 to reinstall the boot file (instead of U5) over jumpstart as its a ldom, noticed a another error. Boot device: /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] File and args: -s Requesting Internet Address for 0:14:4f:f9:84:f3 boot: cannot open kernel/sparcv9/unix Enter filename [kernel/sparcv9/unix]: Has anyone seen this error on U6 jumpstart or is it just me? -- 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] Lost space in empty pool (no snapshots)
I have done some more tests, it seems that if I create a large file with mkfile and interrupt the creation, the space that was allocated is still occupied after I remove the file. I'm gonna file this as a bug if no one has anything to add to this. First I create a new pool, on that pool I create a file and interrupt the creation, after removing that file the space is free again: # uname -a SunOS tank 5.11 snv_101 i86pc i386 i86pc # zpool create tank raidz c1t1d0 c1t2d0 c1t4d0 # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 85.9K 2.66T 24.0K /tank # mkfile 10G /tank/testfile01 ^C# zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 4.73G 2.66T 4.73G /tank # rm /tank/testfile01 && sync # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 85.9K 2.66T 24.0K /tank Now, if I do the same again, but with a very large file: # mkfile 750G /tank/testfile02 ^C# zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 11.3G 2.65T 11.3G /tank # rm /tank/testfile02 && sync zfs list tank# zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 12.2G 2.65T 12.2G /tank # zpool export tank # zpool import tank # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 12.2G 2.65T 12.2G /tank # zpool scrub tank # zpool status tank pool: tank state: ONLINE scrub: scrub completed after 0h1m with 0 errors on Sun Nov 16 01:17:54 2008 config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 raidz1ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 c1t2d0 ONLINE 0 0 0 c1t4d0 ONLINE 0 0 0 errors: No known data errors Some zdb output: # zdb - tank |more Dataset mos [META], ID 0, cr_txg 4, 89.9K, 30 objects, rootbp [L0 DMU objset] 40 0L/200P DVA[0]=<0:c800026800:400> DVA[1]=<0:1926800:400> DVA[2]=<0:26800:400 > fletcher4 lzjb LE contiguous birth=43 fill=30 cksum=af477f73c: 4926037df90:f80a fd99a65f:2399d9c07818be Object lvl iblk dblk lsize asize type 0116K16K16K 8K DMU dnode Object lvl iblk dblk lsize asize type 1116K16K32K 12.0K object directory Fat ZAP stats: Pointer table: 1024 elements zt_blk: 0 zt_numblks: 0 zt_shift: 10 zt_blks_copied: 0 zt_nextblk: 0 ZAP entries: 7 Leaf blocks: 1 Total blocks: 2 zap_block_type: 0x8001 zap_magic: 0x2f52ab2ab zap_salt: 0x1d479cab3 Leafs with 2^n pointers: 9: 1 * Blocks with n*5 entries: 1: 1 * Blocks n/10 full: 1: 1 * Entries with n chunks: 3: 7 *** Buckets with n entries: 0:505 1: 7 * sync_bplist = 21 history = 22 root_dataset = 2 errlog_scrub = 0 errlog_last = 0 deflate = 1 config = 20 Object lvl iblk dblk lsize asize type 2116K512512 0 DSL directory 256 bonus DSL directory creation_time = Sun Nov 16 01:11:53 2008 head_dataset_obj = 16 parent_dir_obj = 0 origin_obj = 14 child_dir_zapobj = 4 used_bytes = 12.2G compressed_bytes = 12.2G uncompressed_bytes = 12.2G quota = 0 reserved = 0 props_zapobj = 3 deleg_zapobj = 0 flags = 1 used_breakdown[HEAD] = 12.2G used_breakdown[SNAP] = 0 used_breakdown[CHILD] = 89.9K used_breakdown[CHILD_RSRV] = 0 used_breakdown[REFRSRV] = 0 Object lvl iblk dblk lsize asize type 3116K512512 2K DSL props microzap: 512 bytes, 0 entries Object lvl iblk dblk lsize asize type 4116K512512 2K DSL directory child map microzap: 512 bytes, 2 entries $MOS = 5 $ORIGIN = 8 Object lvl iblk dblk lsize asize type 5116K512512 0 DSL directory 256 bonus DSL directory creation_time = Sun Nov 16 01:11:53 2008 head_dataset_obj = 0 parent_dir_obj = 2 origin_obj = 0 child_dir_
[zfs-discuss] Fwd: [osol-announce] IMPT: Do not use SXCE Build 102
Heads up! and apologies to folks subscribed to os-announce. -- Forwarded message -- From: Derek Cicero <[EMAIL PROTECTED]> Date: Sat, Nov 15, 2008 at 1:14 PM Subject: [osol-announce] IMPT: Do not use SXCE Build 102 To: [EMAIL PROTECTED], os-discuss <[EMAIL PROTECTED]> Due to the following bug, I have removed build 102 from the Download page. 6771840 zpool online on ZFS root can panic system It apparently may cause data corruption and may have been implicated in damage to one or more systems that have upgraded to build 102 or beyond. We will remove it from the SDLC on Monday. I will notify about the schedule for a repsin. Derek -- Derek Cicero Program Manager Solaris Kernel Group, Software Division ___ opensolaris-announce mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/opensolaris-announce -- Al Hopper Logical Approach Inc,Plano,TX [EMAIL PROTECTED] Voice: 972.379.2133 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Still more questions WRT selecting a mobo for small ZFS RAID
Al Hopper wrote: > On Sat, Nov 15, 2008 at 9:26 AM, Richard Elling <[EMAIL PROTECTED]> wrote: > >> dick hoogendijk wrote: >> >>> On Sat, 15 Nov 2008 18:49:17 +1300 >>> Ian Collins <[EMAIL PROTECTED]> wrote: >>> >>> >>> [EMAIL PROTECTED] wrote: > > WD Caviar Black drive [...] Intel E7200 2.53GHz 3MB L2 > > The P45 based boards are a no-brainer > > 16G of DDR2-1066 with P45 or > 8G of ECC DDR2-800 with 3210 based boards > > That is the question. > > > I guess the answer is how valuable is your data? >>> I disagree. The answer is: go for the 16G and make backups. The 16G >>> system will work far more "easy" and I may be lucky but in the past >>> years I did not have ZFS issues with my non-ECC ram ;-) >>> >>> >> You are lucky. I recommend ECC RAM for any data that you care >> about. Remember, if there is a main memory corruption, that may >> impact the data that ZFS writes which will negate any on-disk >> redundancy. And yes, this does occur -- check the archives for the >> tales of woe. >> > > I agree with your recommendation Richard. OTOH I've built/used a > bunch of systems over several years that were mostly non ECC equipped > and only lost one DIMM along the way. So I guess I've been lucky also > - but IMHO the failure rate for RAM these days is pretty small[1]. > I've also been around hundreds of SPARC boxes and, again, very, few > RAM failures (one is all that I can remember). > > I think the situation will change with the current expansion in RAM sizes. Five years ago with mainly 32 bit x86 systems, 4G of ram was a lot (even on most Sparc boxes). Today 32 and 64GB are becoming common. Desktop systems have seen similar growth. ZFS also uses system RAM in a way it hasn't been used before. Memory that would have been unused or holding static pages is now churning rapidly, in a way similar memory testers like memtest86. Random patterns are cycling though RAM like never before, greatly increasing the chances for hitting a bad bit or addressing error. I've had RAM faults that have taken hours with memtest86 to hit the trigger bit pattern that would have gone unnoticed for years if I hadn't seen data corruption with ZFS. ZFS may turn out to be the ultimate RAM soak tester! -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs not yet suitable for HA applications?
I discussed this exact issue on the forums in February, and filed a bug at the time. I've also e-mailed and chatted with the iSCSI developers, and the iSER developers a few times. There was also been another thread about the iSCSI timeouts being made configurable a few months back, and finally, I started another discussion on ZFS availability, and filed an RFE for pretty much exactly what you're asking for. So the question is being asked, but as for how long it will be before Sun improve ZFS availability, I really wouldn't like to say. One potential problem is that Sun almost certainly have a pretty good HA system with Fishworks running on their own hardware, and I don't know how much they are going to want to create an open source alternative to that. My original discussion in Feb: http://opensolaris.org/jive/thread.jspa?messageID=213482 The iSCSI timeout bugs. The first one was raised in November 2006!! http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=649 http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=a1c19a874eb8bac94084acffabc5?bug_id=6670866 The ZFS availability thread: http://www.opensolaris.org/jive/thread.jspa?messageID=274031 I can't find the RFE I filed on the back of that just yet, I'll have a look through my e-mails on Monday to find it for you. The one bright point is that it does look like it would be possible to edit iscsi.h manually and recompile the driver, but that's a bit outside of my experience right now so I'm leaving that until I have no other choice. Ross -- 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] Still more questions WRT selecting a mobo for small ZFS RAID
On Sat, Nov 15, 2008 at 9:26 AM, Richard Elling <[EMAIL PROTECTED]> wrote: > dick hoogendijk wrote: >> On Sat, 15 Nov 2008 18:49:17 +1300 >> Ian Collins <[EMAIL PROTECTED]> wrote: >> >> >>> [EMAIL PROTECTED] wrote: >>> > WD Caviar Black drive [...] Intel E7200 2.53GHz 3MB L2 > The P45 based boards are a no-brainer 16G of DDR2-1066 with P45 or 8G of ECC DDR2-800 with 3210 based boards That is the question. >>> I guess the answer is how valuable is your data? >>> >> >> I disagree. The answer is: go for the 16G and make backups. The 16G >> system will work far more "easy" and I may be lucky but in the past >> years I did not have ZFS issues with my non-ECC ram ;-) >> > > You are lucky. I recommend ECC RAM for any data that you care > about. Remember, if there is a main memory corruption, that may > impact the data that ZFS writes which will negate any on-disk > redundancy. And yes, this does occur -- check the archives for the > tales of woe. I agree with your recommendation Richard. OTOH I've built/used a bunch of systems over several years that were mostly non ECC equipped and only lost one DIMM along the way. So I guess I've been lucky also - but IMHO the failure rate for RAM these days is pretty small[1]. I've also been around hundreds of SPARC boxes and, again, very, few RAM failures (one is all that I can remember). Risk management is exactly that. You have to determine where the risk is and how important it is and how likely it is to bite. And then allocate costs from your budget to minimize that risk. Remember that you won't totally eliminate all risk - but you can minimize it. At the time when there was a big cost delta between ECC and non ECC RAM parts, I always went with the most (non ECC) RAM that the budget would support. That was my personal risk assessment and priority. I think it was a good decision and it did'nt cause me any grief. [1] I do recommend that you test the heck out of new RAM parts and ensure that they get some airflow - especially if they are getting a supply of hot air from any nearby CPU coolers. Even the simple "finger test" will tell you if you need a fan for your RAM DIMMs. -- Al Hopper Logical Approach Inc,Plano,TX [EMAIL PROTECTED] Voice: 972.379.2133 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best SXCE version for ZFS Home Server
On Sat, Nov 15, 2008 at 10:57 AM, Vincent Boisard <[EMAIL PROTECTED]>wrote: > > >> >> OTOH - if you don't know OpenSolaris well enough, you're better off >> either picking an earlier release that has proven to have very few >> relevant warts - usually based on a recommendation for other, more >> experieced, users. Or you could go with the commercial, rock solid >> release called Solaris U6 (Update 6) recently released. >> > > Where can I find advice on these earlier versions "with few relevant > warts". When I look at forums, I see good and bad for each release. Also, > S10U6 does not have features that I need (Zones ZFS cloning). Also, as I > have no support contract with sun (home user), I am not sure if I will get > patches or not. > > If Zone Cloning via ZFS snapshots is the only feature you miss in S10u6, then you should reconsider. Writing a script to implement this yourself will require only a little experimentation. -- Any sufficiently advanced technology is indistinguishable from magic. Arthur C. Clarke My blog: http://initialprogramload.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Still more questions WRT selecting a mobo for small ZFS RAID
>Henrik Johansson wrote: >> On Nov 15, 2008, at 11:18 AM, [EMAIL PROTECTED] wrote: >> >> I went for a AM2+ GeForce 8200 motherboard which seemed more stable with Solaris than 8300. With the AM2+ socket I can wait for the new 45nm CPUs, I bought the cheapest dual-core I could find for now (which did not support PM). I am very happy with the system except for the fact that the onboard NIC doesn't work. >>> Which NIC is that? >>> >> >> NVIDIA nForce built-in Gigabit MAC with external RTL8211CL-GR (ASUS >> M3N78-AM), both the HCL and some posts in forums stated that it did >> not work, so I bought an Intel card for it also. >> > >RTL8211C IP checksum offload is broken. You can disable it, but you >have to edit /etc/system. See CR 6686415 for details. >http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6686415 > -- richard I think the proper way to state this is "the driver doesn't properly support checksum offload". (In many of the newer realtek cards the way the offload is done is differently) Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS hangs on laptop
I have found the following bug which I can easily reproduce. Right now I'm live
debugging it with a sun developer. Here is a link to the bug in bugtracker
(contains ::threadlist -v output as attachment) and some mdb output:
http://defect.opensolaris.org/bz/show_bug.cgi?id=3690
[EMAIL PROTECTED]:~# echo "dc0e7600::findstack -v" | mdb -k
stack pointer for thread dc0e7600: da867d14
da867d44 swtch+0x195()
da867d54 cv_wait+0x53(daa759aa, daa75968, , 0)
da867d94 txg_wait_open+0x90(daa75800, a511, 0, 2)
da867dd4 dmu_tx_wait+0xdd(d61ec020)
da867e64 zfs_write+0x35f(d6b76ec0, da867efc, 0, da5fe898, 0, dab874d8)
da867eb4 fop_write+0x4a(d6b76ec0, da867efc, 0, da5fe898, 0, 1)
da867f44 write+0x2bb(4, 808, 2, da867fac, fe800c57, 0)
da867f84 dtrace_systrace_syscall+0xc8()
da867fac sys_sysenter+0x106()
[EMAIL PROTECTED]:~# echo "daa75800::print dsl_pool_t dp_tx" | mdb -k
{
dp_tx.tx_cpu = 0xdb523100
dp_tx.tx_sync_lock = {
_opaque = [ 0, 0 ]
}
dp_tx.tx_suspend = {
_opaque = [ 0 ]
}
dp_tx.tx_open_txg = 0xa510
dp_tx.tx_quiesced_txg = 0xa50f
dp_tx.tx_syncing_txg = 0xa50e
dp_tx.tx_synced_txg = 0xa50d
dp_tx.tx_sync_txg_waiting = 0xa38c
dp_tx.tx_quiesce_txg_waiting = 0xa511
dp_tx.tx_sync_more_cv = {
_opaque = 0
}
dp_tx.tx_sync_done_cv = {
_opaque = 0
}
dp_tx.tx_quiesce_more_cv = {
_opaque = 0x1
}
dp_tx.tx_quiesce_done_cv = {
_opaque = 0x1
}
dp_tx.tx_timeout_cv = {
_opaque = 0
}
dp_tx.tx_exit_cv = {
_opaque = 0
}
dp_tx.tx_threads = 0x2
dp_tx.tx_exiting = 0
dp_tx.tx_sync_thread = 0xdbfbbde0
dp_tx.tx_quiesce_thread = 0xdbe84de0
dp_tx.tx_timelimit_thread = 0
}
Regards,
Björn
--
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] Still more questions WRT selecting a mobo for small ZFS RAID
dick hoogendijk wrote: > > Ian Collins <[EMAIL PROTECTED]> wrote: >> >> [EMAIL PROTECTED] wrote: >> >> >>> >>> > WD Caviar Black drive [...] Intel E7200 2.53GHz 3MB L2 >>> >>> > The P45 based boards are a no-brainer >>> >>> >>> >>> 16G of DDR2-1066 with P45 or >>> >>> 8G of ECC DDR2-800 with 3210 based boards >>> >>> >>> >>> That is the question. >>> >>> >> >> I guess the answer is how valuable is your data? >> >> > > I disagree. The answer is: go for the 16G and make backups. getting corruption passing through zil onto disk is a risk, perhaps smaller if metadata, (sole risk to pool integrity) but random system crashes and crupt answers from the arc cache should be expected with 16G filled for months. (still, might not be an issue for a single home user, but if your married it might be :-) the Enterprise version of the above drive is http://www.wdc.com/en/products/Products.asp?DriveID=503 possibly with a desirable faster timeout. Rob ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Still more questions WRT selecting a mobo for small ZFS RAID
Henrik Johansson wrote: > On Nov 15, 2008, at 11:18 AM, [EMAIL PROTECTED] wrote: > > >>> I went for a AM2+ GeForce 8200 motherboard which seemed more stable >>> with Solaris than 8300. With the AM2+ socket I can wait for the new >>> 45nm CPUs, I bought the cheapest dual-core I could find for now >>> (which >>> did not support PM). I am very happy with the system except for the >>> fact that the onboard NIC doesn't work. >>> >> Which NIC is that? >> > > NVIDIA nForce built-in Gigabit MAC with external RTL8211CL-GR (ASUS > M3N78-AM), both the HCL and some posts in forums stated that it did > not work, so I bought an Intel card for it also. > RTL8211C IP checksum offload is broken. You can disable it, but you have to edit /etc/system. See CR 6686415 for details. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6686415 -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Still more questions WRT selecting a mobo for small ZFS RAID
dick hoogendijk wrote: > On Sat, 15 Nov 2008 18:49:17 +1300 > Ian Collins <[EMAIL PROTECTED]> wrote: > > >> [EMAIL PROTECTED] wrote: >> >>> > WD Caviar Black drive [...] Intel E7200 2.53GHz 3MB L2 >>> > The P45 based boards are a no-brainer >>> >>> 16G of DDR2-1066 with P45 or >>> 8G of ECC DDR2-800 with 3210 based boards >>> >>> That is the question. >>> >>> >> I guess the answer is how valuable is your data? >> > > I disagree. The answer is: go for the 16G and make backups. The 16G > system will work far more "easy" and I may be lucky but in the past > years I did not have ZFS issues with my non-ECC ram ;-) > You are lucky. I recommend ECC RAM for any data that you care about. Remember, if there is a main memory corruption, that may impact the data that ZFS writes which will negate any on-disk redundancy. And yes, this does occur -- check the archives for the tales of woe. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS snapshot list
Hi
> [Default] On Sat, 15 Nov 2008 11:37:50 +0200, Mike Futerko
> <[EMAIL PROTECTED]> wrote:
>
>> Hello
>>
>> Is there any way to list all snapshots of particular file system
>> without listing the snapshots of its children file systems?
>
> fsnm=tank/fs;zfs list -rt snapshot ${fsnm}|grep "${fsnm}@"
>
> or even
>
> fsnm=tank/fs;zfs list -r ${fsnm}|grep "${fsnm}@"
Yes, thanks - I know about grep but if you have hundred of thousands of
snapshots grep is what I wanted to avoid. In my case full zfs list -rt
snapshot take hours, while listing snapshot for individual filesystem is
much much quicker :(
Regards
Mike
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Still more questions WRT selecting a mobo for small ZFS RAID
On Sat, 15 Nov 2008 18:49:17 +1300 Ian Collins <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > WD Caviar Black drive [...] Intel E7200 2.53GHz 3MB L2 > > > The P45 based boards are a no-brainer > > > > 16G of DDR2-1066 with P45 or > > 8G of ECC DDR2-800 with 3210 based boards > > > > That is the question. > > > I guess the answer is how valuable is your data? I disagree. The answer is: go for the 16G and make backups. The 16G system will work far more "easy" and I may be lucky but in the past years I did not have ZFS issues with my non-ECC ram ;-) -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D + http://nagual.nl/ | SunOS sxce snv101 ++ + All that's really worth doing is what we do for others (Lewis Carrol) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] 'zfs recv' is very slow
> > Seems like there's a strong case to have such a program bundled in Solaris. > I think, the idea of having a separate configurable buffer program with a high feature set fits into UNIX philosophy of having small programs that can be used as building blocks to solve larger problems. mbuffer is already bundled with several Linux distros. And that is also the reason its feature set expanded over time. In the beginning there wasn't even support for network transfers. Today mbuffer supports direct transfer to multiple receivers, data transfer rate limitation, high/low water mark algorithm, on the fly md5 calculation, multi volume tape access, usage of sendfile, and has a configurable buffer size/layout. So ZFS send/receive is just another use case for this tool. - Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Still more questions WRT selecting a mobo for small ZFS RAID
On Nov 15, 2008, at 11:18 AM, [EMAIL PROTECTED] wrote: >> >> >> I went for a AM2+ GeForce 8200 motherboard which seemed more stable >> with Solaris than 8300. With the AM2+ socket I can wait for the new >> 45nm CPUs, I bought the cheapest dual-core I could find for now >> (which >> did not support PM). I am very happy with the system except for the >> fact that the onboard NIC doesn't work. > > Which NIC is that? NVIDIA nForce built-in Gigabit MAC with external RTL8211CL-GR (ASUS M3N78-AM), both the HCL and some posts in forums stated that it did not work, so I bought an Intel card for it also. Henrik Johansson http://sparcv9.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS snapshot list
[Default] On Sat, 15 Nov 2008 11:37:50 +0200, Mike Futerko
<[EMAIL PROTECTED]> wrote:
>Hello
>
>Is there any way to list all snapshots of particular file system
>without listing the snapshots of its children file systems?
fsnm=tank/fs;zfs list -rt snapshot ${fsnm}|grep "${fsnm}@"
or even
fsnm=tank/fs;zfs list -r ${fsnm}|grep "${fsnm}@"
>Thanks,
>Mike
--
( Kees Nuyt
)
c[_]
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Seeking thoughts on using SXCE rather than Solar 10 on production servers.
Anyone who follows this list we have seen a number of issues with Solaris 10 and ZFS from me this week. We deployed Solaris 10 for the usual conservative reasons, support and stability. Most of my my ZFS experience has been with SXCE and I've seen problems reported and fixed a couple of builds later. The further SXCE moves ahead of Solaris 10 ZFS, the longer (and probably more difficult) the task of back porting these fixes will become. So my question is, for production servers (x4540) that are primarily SMB (80%) and NFS (20%) file servers, would you deploy SXCE with native CIFS support, or Solaris 10/Samba? I wouldn't hesitate to go with the former, relying on Live Upgrade to incorporate fixes rather than patching. Persuading clients may be a little harder! -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Still more questions WRT selecting a mobo for small ZFS RAID
>I looked at this a month back, i was leaning towards intel for >performance and power consumption but went for AMD doe to lack of ECC >support in most of the Intel chipsets. > >I went for a AM2+ GeForce 8200 motherboard which seemed more stable >with Solaris than 8300. With the AM2+ socket I can wait for the new >45nm CPUs, I bought the cheapest dual-core I could find for now (which >did not support PM). I am very happy with the system except for the >fact that the onboard NIC doesn't work. Which NIC is that? Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS snapshot list
Hello Is there any way to list all snapshots of particular file system without listing the snapshots of its children file systems? Thanks, Mike ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best SXCE version for ZFS Home Server
On Sat, Nov 15, 2008 at 12:18 AM, Al Hopper <[EMAIL PROTECTED]> wrote: > > > This has a comparison (at the time) as to what the differences are > > with the different Solaris versions: > > http://blogs.sun.com/weber/entry/solaris_opensolaris_nevada_indiana_sxde > > That's too old to be useful. > I agree with you on this > > > OTOH - if you don't know OpenSolaris well enough, you're better off > either picking an earlier release that has proven to have very few > relevant warts - usually based on a recommendation for other, more > experieced, users. Or you could go with the commercial, rock solid > release called Solaris U6 (Update 6) recently released. > Where can I find advice on these earlier versions "with few relevant warts". When I look at forums, I see good and bad for each release. Also, S10U6 does not have features that I need (Zones ZFS cloning). Also, as I have no support contract with sun (home user), I am not sure if I will get patches or not. > > In any case, load the release you choose, play with it for a week or > so, while running the type of apps you intend to run and see if it > works for you. After that, consider it "production" and load up all > your precious data. > I'll try to do that > > Also - to add yet another dimension to the decision making process - > os2008.11 is due out any day now. I think that this release will be a > winner. You can download and eval the Release Candidate from > http://www.genunix.org/ (based on 101a). The "production" release > can't be far away. To a large extent, os2008.nn will be a better > long-term choice, since it incorporates the new package update > facility. So you'll be able to upgrade any "problem" binaries very > easily and with very little of something going very wrong. > I'd love to go with os2008.nn, but the zones features are too different. I need sparse zones (and branded zones for linux perhaps). Also, I don't have a fast internet connection, so fetching everything from the web every time I create a zone is a bit of a problem. Anyway, thanks for your help, Vincent ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
