Re: [zfs-discuss] Mirroring USB Drive with Laptop for Backup purposes
On 10 maj 2010, at 20.04, Miles Nordin wrote: bh == Brandon High bh...@freaks.com writes: bh The drive should be on the same USB port because the device bh path is saved in the zpool.cache. If you removed the bh zpool.cache, it wouldn't matter where the drive was plugged bh in. I thought it was supposed to go by devid. There was a bug a while ago that Solaris won't calculate devid for devices that say over SCSI they are ``removeable'' because, in the sense that a DynaMO or DVD-R is ``removeable'', the serial number returned by various identity commands or mode pages isn't bound to any set of stored bits, and the way devid's are used throughout Solaris means they are like a namespace or an array-of for a set of bit-stores so it's not appropriate for a DVD-R drive to have a devid. A DVD disc could have one, though---in fact a release of a pressed disc could appropriately have a non-serialized devid. However USB stick designers used to working with Microsoft don't bother to think through how the SCSI architecture should work in a sane world because they are used to reading chatty-idiot Microsoft manuals, so they fill out the page like a beaurocratic form with whatever feels appropriate and mark USB sticks ``removeable'', which according to the standard and to a sane implementer is a warning that the virtual SCSI disk attached to the virtual SCSI host adapter inside the USB pod might be soldered to removeable FLASH chips. It's quite stupid because before the OS has even determined what kind of USB device is plugged in, it already knows the device is removeable in that sense, just like it knows hot-swap SATA is removeable. USB is no more removeable, even in practical use, than SATA. (eSATA! *slap*) Even in the case of CF readers, it's probably wrong most of the time to set the removeable SCSI flag because the connection that's severable is between the virtual SCSI adapter in the ``reader'' and the virtual SCSI disk in the CF/SD/... card, while the removeable flag indicates severability between SCSI disk and storage medium. In the CF/SD/... reader case the serial number in the IDENTIFY command or mode pages will come from CF/SD/... and remain bound to the bits. The only case that might call for setting the bit is where the adapter is synthesizing a fake mode page where the removeable bit appears, but even then the bit should be clear so long as any serialized fields in other commands and mode pages are still serialized somehow (whether synthesized or not). Actual removeable in-the-scsi-standard's-sense HARD DISK drives mostly don't exist, and real removeable things in the real world attach as optical where an understanding of their removeability is embedded in the driver: ANYTHING the cd driver attaches will be treated removeable. consequently the bit is useless to the way solaris is using it, and does little more than break USB support in ways like this, but the developers refuse to let go of their dreams about what the bit was supposed to mean even though a flood of reality has guaranteed at this point their dream will never come true. I think there was some magical simon-sez flag they added to /kernel/drv/whatever.conf so the bug could be closed, so you might go hunting for that flag in which they will surely want you to encode in a baroque case-sensitive undocumented notation that ``The Microtraveler model 477217045 serial 80502813 attached to driver/hub/hub/port/function has a LYING REMOVEABLE FLAG'', but maybe you can somehow set it to '*' and rejoin reality. Still this won't help you on livecd's. It's probably wiser to walk away from USB unless/until there's a serious will to adopt the practical mindset needed to support it reasonably. I'm sorry if I am slow, but I don't get it; Whys isn't devid calculated for removable devices? What does the serial number has to do with devid? /ragge ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Mirroring USB Drive with Laptop for Backup purposes
On 12 maj 2010, at 05.31, Brandon High wrote: On Tue, May 11, 2010 at 8:17 PM, Richard Elling richard.ell...@gmail.com wrote: boot single user and mv it (just like we've done for fstab/vfstab for the past 30+ years :-) It would be nice to have a grub menu item that ignores the cache, so if you know you've removed a USB drive, you don't need to muck about in single user then reboot again. But who needs usability? This is unix, man. But that shouldn't ever be needed, except in this case where there is a bug, should it? Implementing options to work around every thinkable bug would be an interesting problem, but I believe the problem is to hard to be solved in reasonable time. /ragge ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Mirroring USB Drive with Laptop for Backup purposes
On Tue, May 11, 2010 at 10:13 PM, Richard Elling richard.ell...@gmail.com wrote: But who needs usability? This is unix, man. I must have missed something. For the past few years I have routinely booted with unimportable pools because I often use ramdisks. Sure, I get FMA messages, but that doesn't affect the boot. OTOH, I don't try to backup using mirrors. If you boot from usb and move your rpool from one port to another, you can't boot. If you plug your boot sata drive into a different port on the motherboard, you can't boot. Apparently if you are missing a device from your rpool mirror, you can't boot. I haven't tried booting in single user mode in any of these cases because it's been easier to undo the change. If it was possible to pass in a flag from grub to ignore the cache, it would make life a little easier in such cases. -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Mirroring USB Drive with Laptop for Backup purposes
On May 12, 2010, at 3:23 AM, Brandon High wrote: On Tue, May 11, 2010 at 10:13 PM, Richard Elling richard.ell...@gmail.com wrote: But who needs usability? This is unix, man. I must have missed something. For the past few years I have routinely booted with unimportable pools because I often use ramdisks. Sure, I get FMA messages, but that doesn't affect the boot. OTOH, I don't try to backup using mirrors. (..) If it was possible to pass in a flag from grub to ignore the cache, it would make life a little easier in such cases. Recently I have been working on a zpool that refuses to import. During my work I had to boot the server many times in failsafe mode to be able to remove the zpool.cache file, so Brandon's suggestions sounds very reasonable at first. However, I realized that if you import using zpool import -R /altroot your_pool -- it does NOT create a new zpool.cache. So, as long as you use -R, you can safely import pools without creating a new zpool.cache file and your next reboot will not screw up the system. Basically there's no real need to a grub option (actually for a kernel parameter) -- if you have a problem, you go failsafe mode and remove the file, then in your tests you attempt to import using -R so the cache is not re-created and you don't need to go into failsafe mode ever again. best regards, Eduardo Bragatto. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Odd dump volume panic
I just tried moving a dump volume form rpool into another pool so I used zfs send/receive to copy the volume (to keep some older dumps) then ran dumpadm -d to use the new location. This caused a panic. Nothing ended up in messages and needless to say, there isn't a dump! Creating a new volume and using that worked fine. This was on Solaris 10 update 8. Has anyone else seen anything like this? -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Hard drives for ZFS NAS
Hello, I've decided to replace my WD10EADS and WD10EARS drives as I've checked the SMART values and they've accrued some insanely high numbers for the load/unload counts (40K+ in 120 days on one!). I was leaning towards the Black drives but now I'm a bit worried about the TLER lackingness which was a mistake made my previous sysadmin. I'm wondering what other people are using, even though the Green series has let me down, I'm still a Western Digital gal. Would you recommend any of these for use in a ZFS NAS? 4x WD2003FYYS - http://www.wdc.com/en/products/Products.asp?DriveID=732 [RE4] 4x WD2002FYPS - http://www.wdc.com/en/products/products.asp?DriveID=610 [Green] 6x WD1002FBYS - http://www.wdc.com/en/products/Products.asp?DriveID=503 [RE3] What do people already use on their enterprise level NAS's? Any good Seagates? Thanks, Em _ New, Used, Demo, Dealer or Private? Find it at CarPoint.com.au http://clk.atdmt.com/NMN/go/206222968/direct/01/___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
This is how i understand it. I know the network cards are well supported and i know my storage cards are supportedthe onboard sata may work and it may not. If it does, great, i'll use it for booting, if not, this board has 2 onboard bootable USB sticksluckily usb seems to work regardless On Wed, May 12, 2010 at 1:18 AM, Geoff Nordli geo...@gnaa.net wrote: On Behalf Of James C. McPherson Sent: Tuesday, May 11, 2010 5:41 PM On 12/05/10 10:32 AM, Michael DeMan wrote: I agree on the motherboard and peripheral chipset issue. This, and the last generation AMD quad/six core motherboards all seem to use the AMD SP56x0/SP5100 chipset, which I can't find much information about support on for either OpenSolaris or FreeBSD. If you can get the device driver detection utility to run on it, that will give you a reasonable idea. Another issue is the LSI SAS2008 chipset for SAS controller which is frequently offered as an onboard option for many motherboards as well and still seems to be somewhat of a work in progress in regards to being 'production ready'. What metric are you using for production ready ? Are there features missing which you expect to see in the driver, or is it just oh noes, I haven't seen enough big customers with it ? I have been wondering what the compatibility is like on OpenSolaris. My perception is basic network driver support is decent, but storage controllers are more difficult for driver support. My perception is if you are using external cards which you know work for networking and storage, then you should be alright. Am I out in left-field on this? Thanks, Geoff ___ 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] Opteron 6100? Does it work with opensolaris?
On 12/05/10 03:18 PM, Geoff Nordli wrote: I have been wondering what the compatibility is like on OpenSolaris. My perception is basic network driver support is decent, but storage controllers are more difficult for driver support. Now wait just a minute. You're casting aspersions on stuff here without saying what you're talking about, still less where you're getting your info from. Be specific - put up, or shut up. My perception is if you are using external cards which you know work for networking and storage, then you should be alright. Am I out in left-field on this? I believe you are talking through your hat. James C. McPherson -- Senior Software Engineer, Solaris Oracle http://www.jmcp.homeunix.com/blog ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Unexpected rpool mirror behavior found during testing
Thank you very much. I now know that I am not crazy, surprised but not crazy :-). -- 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] Hard drives for ZFS NAS
On Wed, May 12, 2010 at 09:05:14PM +1000, Emily Grettel wrote: Hello, I've decided to replace my WD10EADS and WD10EARS drives as I've checked the SMART values and they've accrued some insanely high numbers for the load/unload counts (40K+ in 120 days on one!). I was leaning towards the Black drives but now I'm a bit worried about the TLER lackingness which was a mistake made my previous sysadmin. I'm wondering what other people are using, even though the Green series has let me down, I'm still a Western Digital gal. Try WD RE3 and RE4 series, no issues here so far. Presumably, 1 TByte would be better than 2 TByte due to resilver times. Some say Hitachis work, too. Would you recommend any of these for use in a ZFS NAS? 4x WD2003FYYS - http://www.wdc.com/en/products/Products.asp?DriveID=732 [RE4] 4x WD2002FYPS - http://www.wdc.com/en/products/products.asp?DriveID=610 [Green] 6x WD1002FBYS - http://www.wdc.com/en/products/Products.asp?DriveID=503 [RE3] What do people already use on their enterprise level NAS's? Any good Seagates? After a 7200.11 debacle (in fact, SMART just told me I've got another deader on my hands) I'm quite leery. Maybe the SAS Seagates are better. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
Now wait just a minute. You're casting aspersions on stuff here without saying what you're talking about, still less where you're getting your info from. Be specific - put up, or shut up. I think he was just trying to tell me that my cpu should be fine, that the only thing which i might have to worry about is network and disk drivers. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Lu creation
Hello, Is there actually any difference in creating a LU with sbdadm create-lu and stmfadm create-lu ? Are there any special cases in which one should be used over another - im thinking here for comstar should i use sbdadm or stmfadm for creating LU's for my zvols ? Thanks -- ing. Vadim Comanescu S.C. Syneto S.R.L. str. Vasile Alecsandri nr 2, Timisoara Timis, Romania ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS High Availability
On May 12, 2010, at 1:17 AM, schickb schi...@gmail.com wrote: I'm looking for input on building an HA configuration for ZFS. I've read the FAQ and understand that the standard approach is to have a standby system with access to a shared pool that is imported during a failover. The problem is that we use ZFS for a specialized purpose that results in 10's of thousands of filesystems (mostly snapshots and clones). All versions of Solaris and OpenSolaris that we've tested take a long time ( hour) to import that many filesystems. I've read about replication through AVS, but that also seems require an import during failover. We'd need something closer to an active- active configuration (even if the second active is only modified through replication). Or some way to greatly speedup imports. Any suggestions? Bypass the complexities of AVS and the start-up times by implementing a ZFS head server in a pair of ESX/ESXi with Hot-spares using redundant back-end storage (EMC, NetApp, Equalogics). Then, if there is a hardware or software failure of the head server or the host it is on, the hot-spare automatically kicks in with the same running state as the original. There should be no interruption of services in this setup. This type of arrangement provides for oodles of flexibility in testing/ upgrading deployments as well. -Ross ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
The problem is the Solaris team and lsi have put a lot of work into the new 2008 cards. Claiming there are issues without listing specific bugs they can address is, I'm sure, frustrating to say the least. On May 12, 2010 8:22 AM, Thomas Burgess wonsl...@gmail.com wrote: Now wait just a minute. You're casting aspersions on stuff here without saying what you're ... I think he was just trying to tell me that my cpu should be fine, that the only thing which i might have to worry about is network and disk drivers. ___ 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] ZIL Ramdisk Tests and very poor OpenSolaris Ramdisk Performance
Hello, probably a lot of people have done this, now its my time. I wanted to test the performance of comstar over 8 GB FC. My Idea was to create a pool from a ramdisk, a thin provisioned zvol over it and so some benchmarks. However performance is worse then to the disk backend. So I measured the ramdisk performance on opensolaris (build 134): -- a) OK whats the max we can do: r...@nexenta3:/volumes# dd if=/dev/zero of=/dev/null bs=8k ^C980922+0 records in 980922+0 records out 8035713024 bytes (8.0 GB) copied, 1.58065 seconds, 5.1 GB/s Thats ok. b) What can we do reqading from the ramdisk r...@nexenta3:/volumes# dd if=/dev/ramdisk/ramdisk of=/dev/null bs=8k ^C297020+0 records in 297019+0 records out 2433179648 bytes (2.4 GB) copied, 2.79683 seconds, 870 MB/s Looks ok c) Ok what can we do writing to the ramdisk ? r...@nexenta3:/volumes# dd if=/dev/zero of=/dev/ramdisk/ramdisk bs=8k ^C71188+0 records in 71188+0 records out 583172096 bytes (583 MB) copied, 1.99645 seconds, 292 MB/s Whats that ?? 300 MB to memory ? Any Tips why the ramdisk performance is so bad ? --- Regards, Robert -- 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] Odd dump volume panic
On 05/12/10 04:29 AM, Ian Collins wrote: I just tried moving a dump volume form rpool into another pool so I used zfs send/receive to copy the volume (to keep some older dumps) then ran dumpadm -d to use the new location. This caused a panic. Nothing ended up in messages and needless to say, there isn't a dump! Creating a new volume and using that worked fine. This was on Solaris 10 update 8. Has anyone else seen anything like this? The fact that a panic occurred is some kind of bug, but I'm also not surprised that this didn't work. Dump volumes have specialized behavior and characteristics and using send/receive to move them (or any other way to move them) is probably not going to work. You need to extract the dump from the dump zvol using savecore and then move the resulting file. Lori ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Hard drives for ZFS NAS
On Wed, May 12, 2010 at 4:05 AM, Emily Grettel emilygrettelis...@hotmail.com wrote: Hello, I've decided to replace my WD10EADS and WD10EARS drives as I've checked the SMART values and they've accrued some insanely high numbers for the load/unload counts (40K+ in 120 days on one!). I was leaning towards the Black drives but now I'm a bit worried about the TLER lackingness which was a mistake made my previous sysadmin. I'm wondering what other people are using, even though the Green series has let me down, I'm still a Western Digital gal. Would you recommend any of these for use in a ZFS NAS? - 4x WD2003FYYS - http://www.wdc.com/en/products/Products.asp?DriveID=732 [RE4] - 4x WD2002FYPS - http://www.wdc.com/en/products/products.asp?DriveID=610 [Green] - 6x WD1002FBYS - http://www.wdc.com/en/products/Products.asp?DriveID=503 [RE3] Skip anything from WD with the word Green in the title. They're all crap, even the RE Greens are crap. (Okay, they might be good for home storage, but definitely not for non-home storage setups.) It's possible to disable the idle timeout using the wdidle3 utility (requires a boot to DOS). We have 8 WD Green 1.5 TB drives in one storage server. Even with the idle timeout disabled (no load/unload cycles), these things are slow. They're not true 7200 RPM drives, and the 64 MB onboard cache doesn't help to hide that. A re-silver of 1 drive takes over 65 hours on an idle system, and close to 100 hours on an active system. In our other storage server, we went with 1.5 TB Seagate 7200.11 drives. Much nicer. Only 32 MB cache, but they're easily twice as fast as the WD Greens. A re-silver of one of these takes about 35 hours. Even when running backups. The WD RE drives are nice as well. All of our 500 GB drives in our storage servers are WD RE Black drives. All of our 400 GB drives are Seagate E-something drives. No complaints about those. But, they're enterprise, RAID-qualified drives. -- Freddie Cash fjwc...@gmail.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Storage 7410 Flush ARC for filebench
On Tue, 11 May 2010, A Darren Dunham wrote: In the pre-ZFS world I would have suggested unmounting the filesystem between runs. With ZFS, I doubt that is sufficient. I would suppose a zpool export/import might be enough, but I'd want to test that as well. Evidence suggests that unmounting the fileysystem is sufficient. For my own little cpio-based benchmark, umount/mount was sufficient to restore uncached behavior. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
From: James C. McPherson [mailto:james.mcpher...@oracle.com] Sent: Wednesday, May 12, 2010 2:28 AM On 12/05/10 03:18 PM, Geoff Nordli wrote: I have been wondering what the compatibility is like on OpenSolaris. My perception is basic network driver support is decent, but storage controllers are more difficult for driver support. Now wait just a minute. You're casting aspersions on stuff here without saying what you're talking about, still less where you're getting your info from. Be specific - put up, or shut up. My perception is if you are using external cards which you know work for networking and storage, then you should be alright. Am I out in left-field on this? I believe you are talking through your hat. James, it is not my intention to cast an aspersion in this thread. I should have worded my reply differently instead of posting my perception, but I really didn't think I would get piled on for it. This subject interests me because we are going to have customers deploy OpenSolaris on their own equipment and I have been concerned about compatibility. Is the MOBO/Chipset/CPU actually something to be worried about with OpenSolaris compatibility? I know this is not an all-encompassing list, but I got my hardware info from the Nexenta site (http://www.nexenta.com/corp/supported-hardware/hardware-supported-list) because that is the distro I started with. Have a great day! Geoff ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Sun X4500 disk drives
We have a 2006 Sun X4500 with Hitachi 500G disk drives. Its been running for over four years and just now fmadm zpool reports a disk has failed. No data was lost (RAIDZ2 + hot spares worked as expected.) But, the server is out of warranty and we have no hardware support on it. I found the Sun part numbers for X4500 replacement drives here: http://docs.sun.com/source/819-4359-18/CH3-maint.html#50499627_22785 I've been waiting for a quote on one for a while. In the meantime, I figure it would be faster and cheaper just to buy a disk drive directly. The /usr/bin/hd program (from the SUNWhd package) gives this info for the failed disk: c5t0d0p0 VN67ZAKLT1MH ATA HITACHI HDS7250S AJ0A 25 C (77 F) It's a Hitachi Deskstar 7K500 model. But, that particular model doesn't seem to be around anymore (P7K500 is all I could find.) I notice the Deskstar lines are the cheapest, consumer level drives--I wonder why they didn't spec the Ultrastar server/nearline drives instead? I read about issues with zfs and write cache: http://opensolaris.org/jive/thread.jspa?messageID=449656tstart=0 Does anyone have any bad experiences replacing a disk on an X4500 with a non-Sun Hitachi? The hdadm tool reports the write cache is enabled on all the disks. Are their any customized firmware on the Sun disks that make them safer for using write cache? 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] Hard drives for ZFS NAS
On Wed, May 12, 2010 at 4:05 AM, Emily Grettel emilygrettelis...@hotmail.com wrote: I'm wondering what other people are using, even though the Green series has let me down, I'm still a Western Digital gal. What do people already use on their enterprise level NAS's? Any good Seagates? FWIW, I looked at the WDs, but went with the Samsung Spinpoint F3 HD103SJ (two 500GB platters) drives instead because they were found to be faster and very reliable in general. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Hard drives for ZFS NAS
On Wed, May 12, 2010 at 4:05 AM, Emily Grettel emilygrettelis...@hotmail.com wrote: I've decided to replace my WD10EADS and WD10EARS drives as I've checked the SMART values and they've accrued some insanely high numbers for the load/unload counts (40K+ in 120 days on one!). Running WDIDLE.EXE on the drives as soon as you install them will help in that regard. I was leaning towards the Black drives but now I'm a bit worried about the TLER lackingness which was a mistake made my previous sysadmin. It was possible to enable TLER with earlier revisions of the drive, but rumors on the tubes seem to imply that the feature has been removed. I think that any of the REx drives would be fine. The 7200 RPM versions are basically the Black drives, and the Green is the GP drive, just with different TLER settings in firmware. Problems that you're having with your current GP drives are likely to manifest with the RE-Green. What do people already use on their enterprise level NAS's? Any good Seagates? The Constellation ES, but it's harder to find at places like Newegg. From what I've read, the Hitachi and Samsung drives both support CCTL, which is in the ATA-8 spec. There's no way to toggle it on from OpenSolaris (yet) and it doesn't persist through reboot so it's not really ideal. Here's a patch to smartmontools that is supposed to enable it. It's in the SVN version 5.40 but not the current 5.39 release: http://www.csc.liv.ac.uk/~greg/projects/erc/ And a DOS-mode app that's supposed to work: http://www.hdat2.com/ -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Hard drives for ZFS NAS
On Wed, May 12 at 8:45, Freddie Cash wrote: On Wed, May 12, 2010 at 4:05 AM, Emily Grettel [1]emilygrettelis...@hotmail.com wrote: Hello, Â I've decided to replace my WD10EADS and WD10EARS drives as I've checked the SMART values and they've accrued some insanely high numbers for the load/unload counts (40K+ in 120 days on one!). Â I was leaning towards the Black drives but now I'm a bit worried about the TLER lackingness which was a mistake made my previous sysadmin. Â I'm wondering what other people are using, even though the Green series has let me down, I'm still a Western Digital gal. Â Would you recommend any of these for use in a ZFS NAS? Â * 4x WD2003FYYS - [2]http://www.wdc.com/en/products/Products.asp?DriveID=732Â [RE4] * 4x WD2002FYPS - [3]http://www.wdc.com/en/products/products.asp?DriveID=610Â [Green] * 6x WD1002FBYS - [4]http://www.wdc.com/en/products/Products.asp?DriveID=503Â [RE3] We use the WD1002FBYS (1.0TB WD RE3) and haven't had an issue yet in our Dell T610 chassis. -- Eric D. Mudama edmud...@mail.bounceswoosh.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Sun X4500 disk drives
- Doug d...@yahoo.com skrev: Does anyone have any bad experiences replacing a disk on an X4500 with a non-Sun Hitachi? The hdadm tool reports the write cache is enabled on all the disks. Are their any customized firmware on the Sun disks that make them safer for using write cache? Compared to what you have now, I gues anything will do. It doesn't need to be 500 gigs, just use something = that size, preferably larger, in case the 500 gigs turns out to be 499. Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 r...@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS High Availability
Ross Walker wrote: On May 12, 2010, at 1:17 AM, schickb schi...@gmail.com wrote: I'm looking for input on building an HA configuration for ZFS. I've read the FAQ and understand that the standard approach is to have a standby system with access to a shared pool that is imported during a failover. The problem is that we use ZFS for a specialized purpose that results in 10's of thousands of filesystems (mostly snapshots and clones). All versions of Solaris and OpenSolaris that we've tested take a long time ( hour) to import that many filesystems. I've read about replication through AVS, but that also seems require an import during failover. We'd need something closer to an active- active configuration (even if the second active is only modified through replication). Or some way to greatly speedup imports. Any suggestions? Bypass the complexities of AVS and the start-up times by implementing a ZFS head server in a pair of ESX/ESXi with Hot-spares using redundant back-end storage (EMC, NetApp, Equalogics). Then, if there is a hardware or software failure of the head server or the host it is on, the hot-spare automatically kicks in with the same running state as the original. By hot-spare here, I assume you are talking about a hot-spare ESX virtual machine. If there is a software issue and the hot-spare server comes up with the same state, is it not likely to fail just like the primary server? If it does not, can you explain why it would not? Cheers Manoj ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS High Availability
schickb wrote: I'm looking for input on building an HA configuration for ZFS. I've read the FAQ and understand that the standard approach is to have a standby system with access to a shared pool that is imported during a failover. The problem is that we use ZFS for a specialized purpose that results in 10's of thousands of filesystems (mostly snapshots and clones). All versions of Solaris and OpenSolaris that we've tested take a long time ( hour) to import that many filesystems. Do you see this behavior - the long import time - during boot-up as well? Or is an issue only during an export + import operation? I suspect that the zpool cache helps a bit (during boot) but does not get rid of the problem completely (unless it has been recently addressed). If it is not an issue during boot-up, I would give the Open HA Cluster/Solaris Cluster a try or check with ha-clusters-disc...@opensolaris.org. Cheers Manoj ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
jcm == James C McPherson james.mcpher...@oracle.com writes: storage controllers are more difficult for driver support. jcm Be specific - put up, or shut up. marvell controller hangs machine when a drive is unplugged marvell controller does not support NCQ marvell driver is closed-source blob sil3124 driver has lost interrupt problems ATI SB600/SB700 AHCI driver has performance problems mpt driver has disconnect under heavy load problems that may or may not be MSI-related mpt driver is closed source blob mpt driver is not SATA framework and thus does not work with DVD-ROMS or with smartctl XXX -- smartctl does work now, with '-d sat,12'? or only AHCI works with that? USUAL SUGGESTION: use 1068e non-raid and mpt driver, live with problems USUAL OPTIMISM: lsi2008 / mega_sas, which i THINK are open source but opengrok seems to be down so I did not verify. My perception is if you are using external cards which you know work for networking and storage, then you should be alright. Am I out in left-field on this? jcm I believe you are talking through your hat. network performance problems with realtek network performance problems with nvidia nforce network working-at-all problems with broadcom bge and bnx because of the ludicrous number of chip steppings and errata closed-source blob drivers with broadcom bnx performance and working-at-all problems for atheros L1 USUAL SUGGESTION: use intel 82540 derivative. which, for an AMD board, will almost always be an external card because AMD boards are usually realtek, broadcom, or marvell for AMD chipsets, and realtek or nforce for nVidia chipsets (if anyone still uses nvidia chipsets). FAIR STATEMENT: Linux shares most of these problems except over there bnx is open source. USUAL OPTIMISM: crossbow-supported cards with L4 classifiers in the MAC other than bnx, such as 10gig ones, may be the future, much more performant, ready for CoS pause frames, and good multicore performance, and having source. god willing their quality might turn out to be more uniform but probably nobody knows yet, and they're not cheap and ubiquitous onboard yet. I'm hoping infiniband comes back and 10gig goes away, but that's probably not realistic. WELL POISONING: saying ``if you want open-source drivers go whine at the hardware vendor because they make us sign an NDA, so there's nothing we can do,'' is hogwash. (a) Sun's the one able to realistically bargain with the vendor, not users, because they bring to the table developer hours, OS support, a class of customers, trusting contacts within the vendor, and a hardware manufacturing arm that can make purchasing decisions long-term and at a motherboard component level; no user has anywhere near this insane level of bargaining power; see OpenBSD presentation and ``the OEM problem'', (b) usually only one chip works anyway, so there is no competition, (c) Linux has open source drivers for all these chips and is an existence proof that yes, you can do something about it, and (d) the competition for users is between Solaris and Linux, not between Marvell and LSI. If we want complete source for the OS we will get it faster and more reliably by going to the OS that offers it, not by whining to chip vendors. This is not flamebait but just obvious reality---so obvious that almost everyone who really cares enough to say it is already gone. HTH, HAND. pgpGJkSjxmX5x.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Mirroring USB Drive with Laptop for Backup purposes
bh == Brandon High bh...@freaks.com writes: bh If you boot from usb and move your rpool from one port to bh another, you can't boot. If you plug your boot sata drive into bh a different port on the motherboard, you can't bh boot. Apparently if you are missing a device from your rpool bh mirror, you can't boot. yeah, this is retarded and should get fixed. bh zpool.cache saves the device path to make importing pools bh faster. It would be nice if there was a boot flag you could bh give it to ignore the file... I've no doubt this is true but ISTR it's not related to the booting problem above becuase I do not think zpool.cache is used to find the root pool. It's only used for finding other pools. ISTR the root pool is found through devid's that grub reads from the label on the BIOS device it picks, and then passes to the kernel. note that zpool.cache is ON THE POOL, so it can't be used to find the pool (ok, it can---on x86 it can be sync'ed into the boot archive, and on SPARC it can be read through the PROM---but although I could be wrong ISTR this is not what's actually done). I think you'll find you CAN move drives among sata ports, just not among controller types, because the devid is a blob generated by the disk driver, and pci-ide and AHCI will yeild up different devid's for the same disk. Grub never calculates a devid, just reads one from the label (reads a devid that some earlier kernel got from pci-ide or ahci and wrote into the label). so when ports and device names change, rewriting labels is helpful but not urgent. When disk drivers change, rewriting labels is urgent. yeah, the fact that ramdisk booting isn't possible with opensolaris makes tihs whole situation a lot more serious than it was back when SXCE was still available for download. Is there any way to make a devid-proof rescue boot option? Is there a way to make grub boot an iso image off the hard disk for example? pgp84LsPjArBH.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Hard drives for ZFS NAS
eg == Emily Grettel emilygrettelis...@hotmail.com writes: eg What do people already use on their enterprise level NAS's? For a SOHO NAS similar to the one you are running, I mix manufacturer types within a redundancy set so that a model-wide manufacturing or firmware glitch like the ones of which we've had several in the last few years does not take out an entire array, and to make it easier to figure out whether weird problems in iostat are controller/driver's fault, or drive's fault. If there are not enough manufacturers with good drives on offer, I'll try to buy two different models of the same manufacturer, ex get one of them an older model number of the same drive size/featureset. Often you find two mini-generations are on offer at once. At the moment, I would not buy any WD drive because they have been changing drives' behavior without changing model numbers which makes pointless discussions like this one because the model numbers become meaningless and you cannot bind your experience to a repeatable purchasing decision other than ``do/don't buy WD''. When the dust settles from this silent-firmware-version-bumps and 4k-sector disaster, I would buy WD again because the more mfg diversity, the more bad-batch-proofing you have for wide stripes. I used to buy near-line drives but no longer do this because it's cheaper to buy two regular drives than one near-line drive, but this may be a mistake because of the whole vibration disaster. pgpRFDcJerIaG.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Sun X4500 disk drives
On Wed, May 12, 2010 at 09:34:28AM -0700, Doug wrote: We have a 2006 Sun X4500 with Hitachi 500G disk drives. Its been running for over four years and just now fmadm zpool reports a disk has failed. No data was lost (RAIDZ2 + hot spares worked as expected.) But, the server is out of warranty and we have no hardware support on it. Well - had the same thing here (X4500, Q1 2007) 2-3 times couple of month ago. The 'too many errors' msg ringed some bells: do you remember the race condition problems in the marvell driver (IIRC especially late u3, u4) which caused many 'bad ...' errors in the logs? So I simply checked the drive in question (QD 2xdd over the whole disk and checked, whether an error occured). Since not a single error or bad performance I put it back and no wonder, it is still working ;-) ). Your situation might be different, but checking may not hurt - your disks might be a victim of an SW aka ZFS error counter... Have fun, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Hard drives for ZFS NAS
bh == Brandon High bh...@freaks.com writes: bh From what I've read, the Hitachi and Samsung drives both bh support CCTL, which is in the ATA-8 spec. There's no way to bh toggle it on from OpenSolaris (yet) and it doesn't persist bh through reboot so it's not really ideal. bh Here's a patch to smartmontools that is supposed to enable bh it. It's in the SVN version 5.40 but not the current 5.39 bh release: http://www.csc.liv.ac.uk/~greg/projects/erc/ That's good to know. It would be interesting to know if the smartctl command in question can actually make it through a solaris system, and on what disk driver. AHCI and mpt are different because one is SATA framework and one isn't. I wonder also if SAS expanders cause any problems for smartctl? also, has anyone actually found this feature to have any value at all? To be clear, I do understand what the feature does. I do not need it explained to me again. but AIUI with ZFS you must remove a partially failing drive, or else the entire pool becomes slow. It does not matter if the partially-failing drive is returning commands in 30sec (the ATA maximum) or 7sec by CCTL/TLER/---you must still find and remove it, or the zpool will become pathologically slow. If there is actual experience with the feature helping ZFS, I'd be interested, but so far I think people are just echoing wikipedia shoulds and speculations, right? pgpOauVvynd3C.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Odd dump volume panic
On 05/13/10 03:27 AM, Lori Alt wrote: On 05/12/10 04:29 AM, Ian Collins wrote: I just tried moving a dump volume form rpool into another pool so I used zfs send/receive to copy the volume (to keep some older dumps) then ran dumpadm -d to use the new location. This caused a panic. Nothing ended up in messages and needless to say, there isn't a dump! Creating a new volume and using that worked fine. This was on Solaris 10 update 8. Has anyone else seen anything like this? The fact that a panic occurred is some kind of bug, but I'm also not surprised that this didn't work. Dump volumes have specialized behavior and characteristics and using send/receive to move them (or any other way to move them) is probably not going to work. You need to extract the dump from the dump zvol using savecore and then move the resulting file. I'm surprised. I thought the volume used for dump is just a normal zvol or other block device. I didn't realise there was any relationship between a zvol and its contents. One odd think I did notice was the device size was reported differently on the new pool: zfs get all space/dump NAMEPROPERTY VALUE SOURCE space/dump type volume - space/dump creation Wed May 12 20:56 2010 - space/dump used 12.9G - space/dump available 201G - space/dump referenced12.9G - space/dump compressratio 1.01x - space/dump reservation none default space/dump volsize 16G- space/dump volblocksize 128K - space/dump checksum on default space/dump compression on inherited from space space/dump readonly offdefault space/dump shareiscsioffdefault space/dump copies1 default space/dump refreservationnone default space/dump primarycache alldefault space/dump secondarycachealldefault space/dump usedbysnapshots 0 - space/dump usedbydataset 12.9G - space/dump usedbychildren0 - space/dump usedbyrefreservation 0 - zfs get all rpool/dump NAMEPROPERTY VALUE SOURCE rpool/dump type volume - rpool/dump creation Thu Jun 25 19:40 2009 - rpool/dump used 16.0G - rpool/dump available 10.4G - rpool/dump referenced16K- rpool/dump compressratio 1.00x - rpool/dump reservation none default rpool/dump volsize 16G- rpool/dump volblocksize 8K - rpool/dump checksum offlocal rpool/dump compression offlocal rpool/dump readonly offdefault rpool/dump shareiscsioffdefault rpool/dump copies1 default rpool/dump refreservationnone default rpool/dump primarycache alldefault rpool/dump secondarycachealldefault -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Sun X4500 disk drives
On 05/13/10 08:55 AM, Jens Elkner wrote: On Wed, May 12, 2010 at 09:34:28AM -0700, Doug wrote: We have a 2006 Sun X4500 with Hitachi 500G disk drives. Its been running for over four years and just now fmadm zpool reports a disk has failed. No data was lost (RAIDZ2 + hot spares worked as expected.) But, the server is out of warranty and we have no hardware support on it. Well - had the same thing here (X4500, Q1 2007) 2-3 times couple of month ago. The 'too many errors' msg ringed some bells: do you remember the race condition problems in the marvell driver (IIRC especially late u3, u4) which caused many 'bad ...' errors in the logs? So I simply checked the drive in question (QD 2xdd over the whole disk and checked, whether an error occured). Since not a single error or bad performance I put it back and no wonder, it is still working ;-) ). This backs up my experiences with x4500s. I have had several drives fail which I have taken off line and thrashed with format for a couple of days without finding any errors. Out of 9 or 10 failures only one was FUBAR. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS High Availability
On May 12, 2010, at 3:06 PM, Manoj Joseph manoj.p.jos...@oracle.com wrote: Ross Walker wrote: On May 12, 2010, at 1:17 AM, schickb schi...@gmail.com wrote: I'm looking for input on building an HA configuration for ZFS. I've read the FAQ and understand that the standard approach is to have a standby system with access to a shared pool that is imported during a failover. The problem is that we use ZFS for a specialized purpose that results in 10's of thousands of filesystems (mostly snapshots and clones). All versions of Solaris and OpenSolaris that we've tested take a long time ( hour) to import that many filesystems. I've read about replication through AVS, but that also seems require an import during failover. We'd need something closer to an active- active configuration (even if the second active is only modified through replication). Or some way to greatly speedup imports. Any suggestions? Bypass the complexities of AVS and the start-up times by implementing a ZFS head server in a pair of ESX/ESXi with Hot-spares using redundant back-end storage (EMC, NetApp, Equalogics). Then, if there is a hardware or software failure of the head server or the host it is on, the hot-spare automatically kicks in with the same running state as the original. By hot-spare here, I assume you are talking about a hot-spare ESX virtual machine. If there is a software issue and the hot-spare server comes up with the same state, is it not likely to fail just like the primary server? If it does not, can you explain why it would not? That's a good point and worth looking into. I guess it would fail as well as a vmware hot-spare is like a vm in constant vmotion where active memory is mirrored between the two. I suppose one would need a hot-spare for hardware failure and a cold- spare for software failure. Both scenarios are possible with ESX, the cold spare I suppose in this instance would be the original VM rebooting. Recovery time would be about the same in this instance as an AVS solution that has to mount 1 mounts though, so it wins with a hardware failure and ties with a software failure, but wins with ease of setup and maintenance, but looses with additional cost. Guess it all depends on your risk analysis whether it is worth it. -Ross ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS High Availability
On May 11, 2010, at 10:17 PM, schickb wrote: I'm looking for input on building an HA configuration for ZFS. I've read the FAQ and understand that the standard approach is to have a standby system with access to a shared pool that is imported during a failover. The problem is that we use ZFS for a specialized purpose that results in 10's of thousands of filesystems (mostly snapshots and clones). All versions of Solaris and OpenSolaris that we've tested take a long time ( hour) to import that many filesystems. I've read about replication through AVS, but that also seems require an import during failover. We'd need something closer to an active-active configuration (even if the second active is only modified through replication). Or some way to greatly speedup imports. Any suggestions? The import is fast, but two other operations occur during import that will affect boot time: + for each volume (zvol) and its snapshots, a device tree entry is made in /devices + for each NFS share, the file system is (NFS) exported When you get into the thousands of datasets and snapshots range, this takes some time. Several RFEs have been implemented over the past few years to help improve this. NB. Running in a VM doesn't improve the share or device enumeration time. -- richard -- ZFS storage and performance consulting at http://www.RichardElling.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
On 12/05/10 11:21 PM, Thomas Burgess wrote: Now wait just a minute. You're casting aspersions on stuff here without saying what you're talking about, still less where you're getting your info from. Be specific - put up, or shut up. I think he was just trying to tell me that my cpu should be fine, that the only thing which i might have to worry about is network and disk drivers. If you are worrying about your network and disk controller drivers, then you need to give some information about what you believe any problems are. So far, there's been a bunch of FUD cast on a driver that I worked on (mpt_sas), and I'm still trying to find out from you and others what you think is a problem with it. James C. McPherson -- Senior Software Engineer, Solaris Oracle http://www.jmcp.homeunix.com/blog ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
I've gotten a couple of the newest prototype AMD systems, with the C34 and G34 sockets. All have run various flavors of OpenSolaris quite well, with the exception of a couple of flaky network problems, which we've tracked down to pre-production NIC hardware and early-access drivers. This is a similar problem I see all the time on prototype Intel stuff. The problems go away when we put in production-ready NIC cards (even when such NIC cards have the same actual chip series, the bugs inevitably are nailed to the beta-level original NIC chips). So I would NOT expect any problems if your MB passes the Device Check tool (or whatever we're calling it nowadays). -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
On 05/13/10 12:46 PM, Erik Trimble wrote: I've gotten a couple of the newest prototype AMD systems, with the C34 and G34 sockets. All have run various flavors of OpenSolaris quite well, with the exception of a couple of flaky network problems, which we've tracked down to pre-production NIC hardware and early-access drivers. This is a similar problem I see all the time on prototype Intel stuff. The problems go away when we put in production-ready NIC cards (even when such NIC cards have the same actual chip series, the bugs inevitably are nailed to the beta-level original NIC chips). So I would NOT expect any problems if your MB passes the Device Check tool (or whatever we're calling it nowadays). Bit of a chicken and egg that, isn't it? You need to run the tool to see if the board's worth buying and you need to buy the board to run the tool! -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
On Thu, 2010-05-13 at 13:25 +1200, Ian Collins wrote: On 05/13/10 12:46 PM, Erik Trimble wrote: I've gotten a couple of the newest prototype AMD systems, with the C34 and G34 sockets. All have run various flavors of OpenSolaris quite well, with the exception of a couple of flaky network problems, which we've tracked down to pre-production NIC hardware and early-access drivers. This is a similar problem I see all the time on prototype Intel stuff. The problems go away when we put in production-ready NIC cards (even when such NIC cards have the same actual chip series, the bugs inevitably are nailed to the beta-level original NIC chips). So I would NOT expect any problems if your MB passes the Device Check tool (or whatever we're calling it nowadays). Bit of a chicken and egg that, isn't it? You need to run the tool to see if the board's worth buying and you need to buy the board to run the tool! *Somebody* has to be that first early adopter. After that, we all get to ride on their experience. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Hard drives for ZFS NAS
Miles Nordin wrote: bh == Brandon High bh...@freaks.com writes: bh From what I've read, the Hitachi and Samsung drives both bh support CCTL, which is in the ATA-8 spec. There's no way to bh toggle it on from OpenSolaris (yet) and it doesn't persist bh through reboot so it's not really ideal. bh Here's a patch to smartmontools that is supposed to enable bh it. It's in the SVN version 5.40 but not the current 5.39 bh release: http://www.csc.liv.ac.uk/~greg/projects/erc/ That's good to know. It would be interesting to know if the smartctl command in question can actually make it through a solaris system, and on what disk driver. AHCI and mpt are different because one is SATA framework and one isn't. I wonder also if SAS expanders cause any problems for smartctl? So, using latest SVN of smartmontools: AHCI reads work, writes don't (could be the drive - a WDC WD3200KS-00PFB0), must specify -d sat,12 to get anything: root:gandalf 0 # ./smartctl -d sat,12 -l scterc,70,70 /dev/rdsk/c9t0d0p0 smartctl 5.40 2010-05-12 r3104 [i386-pc-solaris2.11] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net SCT Error Recovery Control: Read: 57345 (5734.5 seconds) Write: 57345 (5734.5 seconds) mpt nothing works (and I see reports from Windows that it should with this disk, a ST31500341AS with CC1H firmware): root:gandalf 1 # ./smartctl -d sat,12 -l scterc /dev/rdsk/c7t9d0 smartctl 5.40 2010-05-12 r3104 [i386-pc-solaris2.11] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Error Write SCT Error Recovery Control Command failed: scsi error unknown error (unexpected sense key) Warning: device does not support SCT (Get) Error Recovery Control command root:gandalf 4 # ./smartctl -d sat,16 -l scterc /dev/rdsk/c7t9d0 smartctl 5.40 2010-05-12 r3104 [i386-pc-solaris2.11] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Error Write SCT Error Recovery Control Command failed: scsi error unknown error (unexpected sense key) Warning: device does not support SCT (Get) Error Recovery Control command ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
Bit of a chicken and egg that, isn't it? You need to run the tool to see if the board's worth buying and you need to buy the board to run the tool! *Somebody* has to be that first early adopter. After that, we all get to ride on their experience. I am sure the Tier-1 stuff will work just fine. I have an HP unit on order thus : HP Proliant DL165G7 server, 1U Rack Server, 2 × AMD Opteron Processor Model 6172 ( 12 core, 2.1 GHz, 12MB Level 3 Cache, 80W), dual socket configuration for 24-cores in total, 16GB (8 x 2GB) Advanced ECC PC3-10600R (RDIMM) memory, Twenty Four DIMM slots, 2 PCI-E Slots ( 1 PCI Express expansion slot 1, low-profile, half-length and PCI Express expansion slot 2 full height full length ×16 75W +EXT 75W with optional PCI-X support ), 2x HP NC362i Integrated Dual Port Gigabit Server Adapter, Storage Controller (1) Smart Array P410i/256MB BBWC, single HP 500W CS HE Power Supply, no internal HDD, slim height 9.5mm DVD included, no OS - no Monitor, 3 year warranty So when it gets in I'll toss it into a rack, hook up a serial cable and then boot *whatever* as verbosely as possible.[1] If you want you can ssh in to the blastwave server farm and jump on that also ... I'm always game to play with such things. -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris [1] ummm No, I won't be installing Microsoft Windows 7 64-bit Ultimate Edition. .. or maybe I will :-P ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
