Re: [zfs-discuss] Hard drives for ZFS NAS
I use the RE4's at work on the storage server, but at home I use the consumer 1TB green drives. My system [2009.06] uses an Intel Atom 330 based motherboard, 4 gigs of non-ecc ram, a Supermicro AOC-SAT2-MV8 controller with 5 1TB Western Digital [WD10EARS] drives in a raidz1. There are many reasons why this set-up isn't optimal, but in the nine months it's been online, it hasn't produced a single error. -- 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
I did some more research and the findings were very interesting. I bought an Samsung HD103SJ (1tb 7200rpm with two 500gb platters). When you boot the drive cold, SCT error recovery is set at 0 (infinite). This is viewable via HDAT2 and a dos boot. When you load OpenSolaris and run smartctl to set error recovery time, you get the same response as what was received for my old-style WD Caviar Blacks: SCT Error Recovery Control: Read: 57345 (5734.5 seconds) Write: 57345 (5734.5 seconds) *However, when you reboot the machine and check the settings using HDAT2, the settings are correctly updated to whatever you told smartctl to do.* This was case for both the older caviar black and the Samsung drive. So smartctl is in fact setting the drives correctly, but apparently can't read back the success. I can also confirm that the change only holds until poweroff. As such, so you'll have to add it to a boot script. So there you go, a viable replacement for the Caviar Black with short error recovery. I plan on using the HD103SJ drives for my next build out. Now if we can just get rid of those pesky errors that occur when running... Couple of other interesting tidbits: My old-style caviar black drives were originally set at 7s using wdtler. This is what HDAT2 reveals on a cold boot for the error recovery time. You can override that using HDAT2 or smartctl. Upon warm reboot, the updated numbers stick. However, upon cold boot the drive goes back to what was set using wdtler. (I guess according to spec...) For those that are interested, WD changed the extended model number between the old-style caviar black drives and the bad ones but they have the same firmware revision listed (it appears). Working output: Old Style Caviar Black with TLER #./smartctl -d sat,12 /dev/rdsk/c5t1d0s0 -i === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Black family Device Model: WDC WD1001FALS-00E8B0 Serial Number:WD-WMATV422 Firmware Version: 05.00K05 User Capacity:1,000,204,886,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Thu May 13 17:42:16 2010 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled # ./smartctl -d sat,12 /dev/rdsk/c5t1d0s0 -l scterc,70,70 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) New Caviar Black without TLER #./smartctl -d sat,12 /dev/rdsk/c5t3d0s0 -i === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Black family Device Model: WDC WD1001FALS-00J7B1 Serial Number:WD-WMATV649 Firmware Version: 05.00K05 User Capacity:1,000,204,886,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Thu May 13 17:43:01 2010 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled # ./smartctl -d sat,12 /dev/rdsk/c5t3d0s0 -l scterc,70,70 smartctl 5.40 2010-05-12 r3104 [i386-pc-solaris2.11] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Warning: device does not support SCT Error Recovery Control command ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Moved disks to new controller - cannot import pool even after moving ba
I have moved drives between controllers, rearranged drives in other slots, and moved disk sets between different machines and I've never had an issue with a zpool not importing. Are you sure you didn't remove the drives while the system was powered up? Try this: zpool import -D If zpool lists the pool as destroyed, you can re-import it by doing this: zpool import -D vault I know this is a shot in the dark — sorry for not having a better idea. -- 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] ZFS High Availability
On May 12, 2010, at 7:12 PM, Richard Elling wrote: 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. The idea I propose is to use VMs in a manner such that the server does not have to be restarted in the event of a hardware failure thus avoiding the enumerations by using VMware's hot-spare VM technology. Of course using VMs could also mean the OP could have multiple ZFS servers such that the datasets could be spread evenly between them. This could conceivably be done in containers within the 2 original VMs so as to maximize ARC space. -Ross ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Odd dump volume panic
On Wed, May 12, 2010 at 2:19 PM, Ian Collins wrote: > space/dump compression on inherited from > space I'm pretty sure you can't have compression or dedup enabled on a dump volume. -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
> "bh" == Brandon High writes: bh> The devid for a USB device must change as it moves from port bh> to port. I guess it was tl;dr the first time I said this, but: the old theory was that a USB device does not get a devid because it is marked ``removeable'' in some arcane SCSI page, for the same reason it doesn't make sense to give a CD-ROM a devid because its medium can be removed. I don't know if this has changed, or if it's even what's really going on. but like I said without the ramdisk boot option it's more important to fix this type of problem, so if someone has a workaround please share! pgpkdrT55NtZq.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] mirror resilver @500k/s
Hello, I'm a grown-up and willing to read, but I can't find where to read. Please point me to the place that explains how I can diagnose this situation: adding a mirror to a disk fills the mirror with an apparent rate of 500k per second. 1) what diagnostic information should I look at (and perhaps provide to you people here)? 2) how should I have gone about seeking help for a problem like this? 3) on a related note -- why is "zpool status -v data" slower to run as root than it is as a normal user? Thanks for your time! Oliver os10...@giant:~$ (zpool status -v data; zpool iostat -v data; dmesg | tail -5) | egrep -v '^$' pool: data state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 12h13m, 45.74% done, 14h29m to go config: NAMESTATE READ WRITE CKSUM dataONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c9t3d0 ONLINE 0 0 0 c9t1d0 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 c9t2d0 ONLINE 0 0 0 c9t0d0 ONLINE 0 0 0 20.4G resilvered errors: No known data errors capacity operationsbandwidth poolalloc free read write read write -- - - - - - - data 755G 1.76T 67 3 524K 14.1K mirror 530G 1.29T 6 1 40.8K 5.89K c9t3d0 - - 3 1 183K 6.04K c9t1d0 - - 3 0 183K 6.04K mirror 224G 472G 60 1 484K 8.24K c9t2d0 - - 13 0 570K 4.05K c9t0d0 - - 0 34 17 490K -- - - - - - - May 13 10:33:38 giant genunix: [ID 936769 kern.notice] sv0 is /pseudo/s...@0 May 13 10:33:38 giant pseudo: [ID 129642 kern.notice] pseudo-device: ii0 May 13 10:33:38 giant genunix: [ID 936769 kern.notice] ii0 is /pseudo/i...@0 May 13 10:34:34 giant su: [ID 810491 auth.crit] 'su root' failed for os1 on /dev/pts/4 May 13 20:44:09 giant pcplusmp: [ID 805372 kern.info] pcplusmp: ide (ata) instance 1 irq 0xf vector 0x45 ioapic 0x4 intin 0xf is bound to cpu 6 -- 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] Using WD Green drives?
On Thu, May 13, 2010 at 3:19 AM, Roy Sigurd Karlsbakk wrote: > I've been reading a little, and it seems using WD Green drives isn't very > popular in here. Can someone explain why these are so much worse than others? > Usually I see drives go bad with more or less the same frequency... I've been using 8 in a raidz2 for about a year and haven't had any serious problems with them, but I changed the idle timer and TLER settings before doing anything else. They are slow, especially on random read or writes access. Adding a slog / l2arc on ssd has helped a lot with this. Sequential access is fast. On the plus side, the Greens are 5400rpm and generate less heat and noise. If you're aware of their potential shortcomings and what to expect performance-wise, there's no real problem with them. When it comes time to replace them (in 1.5 years while they are still under warranty) I will probably go with a faster drive. I'd also consider using 2.5" drives at this point. -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 Wed, May 12, 2010 at 1:39 PM, Miles Nordin wrote: > 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 Ok, that makes more sense with what I've experienced. The devid for a USB device must change as it moves from port to port. When moving a USB stick I built on one system to another, I had to run bootadm update-archive from the LiveCD. > 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 The testing that I did with moving the sata port may have been across controllers. > devid-proof rescue boot option? Is there a way to make grub boot an > iso image off the hard disk for example? It's probably possible to use the LiveCD / LiveUSB with a custom grub menu item. -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] Moved disks to new controller - cannot import pool even after moving back
When I boot up without the disks in the slots. I manually bring the pool on line with zpool clear I believe that was what you were missing from your command. However I did not try to change controller. Hopefully you only been unplug disks while the system is turn off. If that's case the pool should still be in consistent state. Otherwise, you may want to consider leave the first disk you removed unplug until you bring up the pool on-line then re-add the device back in. (first out last in). Good Luck. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS Oracle white paper is live
http://developers.sun.com/solaris/howtoguides/wp-oraclezfsconfig-0510_ds_ac2.pdf /d ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Using WD Green drives?
On Thu, May 13, 2010 at 9:09 AM, Roy Sigurd Karlsbakk wrote: > 1. even though they're 5900, not 7200, benchmarks I've seen show they are > quite good > They have a 64 MB cache onboard, which hides some of their slowness. But they are slow. > 3. what is TLER? > Time Limited Error Reporting, I think. It's a RAID feature where the drive will only try for X seconds to read a sector and then fail so that the RAID controller can take action. Non-RAID drives will tend to continue trying to read a sector for aeons before giving up leading to timeouts and whatnot further up the storage stack. For ZFS systems, this may not be too big of a deal. > 4. I thought most partitions were aligned at 4k these days? > > Nope. Most disk partitioning tools still use the old "start after 63 sectors for cylinder alignment", which creates a non-4 KB-aligned first partition, and thus non-aligned filesystems. This is why the WD Advanced Format drives come with a hardware jumper to shift numbering by 1 (partition is created at the 63rd logical sector, which is actually the 64th physical sector). However, Unix disk partitioning tools are getting better at this, and it seems that the new "standard" will be to create the first partition at the 1 MB mark. This is then aligned for everything up to 256 KB sectors or something like that. :) There's a list somewhere that shows the status of all the Linux partitioning tools. Not sure about Solaris. FreeBSD partitioning tools doesn't "do the right thing" yet, but allows you to manually specify the starting offset so you can manually align things. > We don't need too much speed on this system, we're still limited to 1Gbps > ethernet, and it's mostly archive data, no reads exceeding the ethernet > bandwidth > If you absolutely must use these drives, then download the wdidle3 utility, stick it on a DOS boot disk, attach the disk to a SATA port on the motherboard, boot to DOS, and disable the idle timeout. Do this for every disk, *before* you put it into the system where they'll be used. You'll save yourself a lot of headaches. :) And the drives will last longer than 3 months or so. (If they've removed the download for wdidle3, I have a copy here.) -- Freddie Cash fjwc...@gmail.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Using WD Green drives?
1. even though they're 5900, not 7200, benchmarks I've seen show they are quite good 3. what is TLER? 4. I thought most partitions were aligned at 4k these days? We don't need too much speed on this system, we're still limited to 1Gbps ethernet, and it's mostly archive data, no reads exceeding the ethernet bandwidth Vennlige hilsener 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] Hard drives for ZFS NAS
I just tried as well on osol134. I have the Western Digital Caviar black drives that still support tler (the older ones). Same result: no changes occur. This is on a 3420 ibex peak chipset Device Model: WDC WD1001FALS-00E8B0 Firmware: 05.00K05 $ pfexec ./smartctl -d sat,12 /dev/rdsk/c5t0d0s0 -l scterc,70,70 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) Now if somebody could just try it on a HD103SJ and a HD502HJ... For those that are interested. It seems to be talking to the drive as when I run it against an Intel x25v ssd (Model INTEL SSDSA2M040G2GC firmware: 2CV102HD): $ pfexec ./smartctl -d sat,12 /dev/rdsk/c5t5d0s0 -l scterc smartctl 5.40 2010-05-12 r3104 [i386-pc-solaris2.11] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Warning: device does not support SCT Commands -Jacques > 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] Using WD Green drives?
On Thu, May 13, 2010 at 3:19 AM, Roy Sigurd Karlsbakk wrote: > I've been reading a little, and it seems using WD Green drives isn't very > popular in here. Can someone explain why these are so much worse than > others? Usually I see drives go bad with more or less the same frequency... > > 1. They're 5900 RPM drives, not 7200, making them even slower than normal SATA drives. 2. They come with a idle timeout of 8 seconds, after which the drive heads are parked. This shows up as the Load Store counter in SMART output. They're rated for around 300,000 or 500,000 load cycle, which can happen in only a few short months on a server (we had over 40,000 in a week on one drive). On some firmware versions, this can be disabled completely using the wdidle3 DOS app. On other firmware versions, this can't be disabled, but can be set to 362 seconds (or something like that). Each time the heads are parked, it takes a couple of seconds to bring the drive back up to speed. This can drop your pool disk I/O through the floor. 3. The firmware on the drives disables the time-limited error reporting (TLER) feature, and it cannot be enabled like on other WD drives. 4. Some of the Green drives are "Advanced Format" with 4 KB sectors, except that the drives all lie and say they use 512 B sectors, leading to all kinds of alignment issues and even more slow-downs. No matter which firmware you run, you cannot get the drives to report on the actual physical size of a disk sector, it always reports 512 B. This makes it very hard to align partitions and filesystems, further degrading performance. If you are building a system that needs to be quiet and power efficient with 2 TB of storage, then maybe using a single WD Green drive would be okay. Maybe a home media server. However, going with 2.5" drives may be better. But for any kind of bulk storage setup or non-home-desktop setup, you'll want to avoid all of the WD Green drives (including the RE Green-power), and also avoid any 5900 RPM drives from other manufacturers (some Seagate 2 TB, for example). We made the mistake of putting 8 WD Green 1.5 TB drives into one of our storage servers, as they were on sale for $100 CDN. Throughput on that server has dropped quite a bit (~200 MB/s instead of the 300+ MB/s we had with all WD RE Black drives). It takes over 65 hours to resilver a single 1.5 TB drive, and a scrub on the entire pool takes over 3 days. When upgrading our secondary storage server, we went with Seagate 7200.11 1.5 TB drives. Re-silver of a drive takes under 35 hours (first drive was over 35 hours, 6th drive was just under). Haven't scrubbed the pool yet (still replacing drives in the raidz2 vdev). Performance has improved slightly, though. -- Freddie Cash fjwc...@gmail.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Using WD Green drives?
(3) Was more about the size than the Green vs. Black issue. This is all assuming most people are looking at green drives for the cost benefits associated with their large sizes. You are correct Green and Black would most likely have the same number of platters per size. -- 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] Opteron 6100? Does it work with opensolaris?
I ordered it. It should be here monday or tuesday. When i get everything built and installed, i'll report back. I'm very excited. I am not expecting problems now that i've talked to supermicro about it. Solaris 10 runs for them so i would imagine opensolaris should be fine too. On Thu, May 13, 2010 at 4:43 AM, Orvar Korvar < knatte_fnatte_tja...@yahoo.com> wrote: > Great! Please report here so we can read about your impressions. > -- > This message posted from opensolaris.org > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Using WD Green drives?
On 13 May, 2010 - Roy Sigurd Karlsbakk sent me these 2,9K bytes:
> - "Brian" skrev:
>
> > (1) They seem to have a firmware setting (that may not be modified
> > depending on revision) that has to do with the drive "parking" the
> > drive after 8 seconds of inactivity to save power. These drives are
> > rated for a certain number of park/unpark operations -- I think
> > 300,000. Using these drives in a NAS results in a lot of
> > park/unpark.
>
> 8 seconds? is it really that low?
Yes. My disk went through 180k in like 2-3 months.. Then I told smartd
to poll the disk every 5 seconds to prevent it from falling asleep.
/Tomas
--
Tomas Ögren, st...@acc.umu.se, http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,acc}.umu.se
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Using WD Green drives?
- "Brian" skrev: > (1) They seem to have a firmware setting (that may not be modified > depending on revision) that has to do with the drive "parking" the > drive after 8 seconds of inactivity to save power. These drives are > rated for a certain number of park/unpark operations -- I think > 300,000. Using these drives in a NAS results in a lot of > park/unpark. 8 seconds? is it really that low? > (2) They are big and slow. This seems to be a very bad combination > for RAIDZ(n). I have seen people report resilvering times of 2 to 4 > days. I am not sure how much that impact performance. But that can > be a long time to run in a degraded state for some people. I don't > know how the resilvering process works - so I don't know if it is a > ZFS issue or not.. Regardless of the drive speed it seems like more > than 2 days to write 1 to 2 TB worth of data is ridiculous - but no > one seems to complain that it is ZFS's fault - so there must be a lot > involved in resilvering that I don't understand. I think that small > and slow would be OK - if you had 500GB green drives you might be > fine.. But people tend to look at the green drives because they have > so much capacity for the money - so I haven't seen anyone say that a > Green 500GB drives work well. We have a green array of 3x7 2TB drives in raidz2 (27TiB), almost full, and it takes some two and a half days to scrub it. Does anyone have scrub times for similar setups with, say, Black drives? > (3) They seem to have a lot of platters.. 3 or 4. More platters == > more heat == more failure... apparently. I somehow doubt Black drives have less platters 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] Using WD Green drives?
I am new to OSOL/ZFS myself -- just placed an order for my first system last week. However, I have been reading these forums for a while - a lot of the data seems to be anecdotal, but here is what I have gathered as to why the WD green drives are not a good fit for a RAIDZ(n) system. (1) They seem to have a firmware setting (that may not be modified depending on revision) that has to do with the drive "parking" the drive after 8 seconds of inactivity to save power. These drives are rated for a certain number of park/unpark operations -- I think 300,000. Using these drives in a NAS results in a lot of park/unpark. (2) They are big and slow. This seems to be a very bad combination for RAIDZ(n). I have seen people report resilvering times of 2 to 4 days. I am not sure how much that impact performance. But that can be a long time to run in a degraded state for some people. I don't know how the resilvering process works - so I don't know if it is a ZFS issue or not.. Regardless of the drive speed it seems like more than 2 days to write 1 to 2 TB worth of data is ridiculous - but no one seems to complain that it is ZFS's fault - so there must be a lot involved in resilvering that I don't understand. I think that small and slow would be OK - if you had 500GB green drives you might be fine.. But people tend to look at the green drives because they have so much capacity for the money - so I haven't seen anyone say that a Green 500GB drives work well. (3) They seem to have a lot of platters.. 3 or 4. More platters == more heat == more failure... apparently. (4) The larger WD drives are 4k sectors which is fine by itself, but because windows XP doesn't like that they have some weird firmware stuff in there to emulate different sector sizes. I am not sure it can be disabled or if it is in fact a problem, but I have seen it mentioned in various gripes. Like I said, I am no expert. But these factors made me choose 1TB samsung spinpoints for my Raidz2 config that I just ordered. I may look into some of these green drives for a secondary mirror zpool at some point - I have some items where I don't need need great redundancy and can trade off speed for cost. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Using WD Green drives?
Hi all I've been reading a little, and it seems using WD Green drives isn't very popular in here. Can someone explain why these are so much worse than others? Usually I see drives go bad with more or less the same frequency... 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
[zfs-discuss] Moved disks to new controller - cannot import pool even after moving back
Hi! I feel panic is close... Short version: I moved the disks of a pool to a new controller without exporting it first. Then I moved them back to the original controller, but I still cannot import the pool. I am new to Opensolaris and ZFS - have set up a box to keep my images and videos. ASUS motherboard, AMD Phenom II CPU, 4GB RAM, SASUC8I 8-port disk controller. 4x500GB disks in a raid1 setup in external eSATA disk cabinets. After some time I decided to do mirrors, so I put in another 4x500GB in two mirrors. These I put in Chieftec backplanes. Started copying the files from the raid pool to the mirrored pool. Yesterday I decided to move the first 4 disks (with the raid pool) from the external encosures to the backplanes. Being tired after work and late at night I forgot to export the pool before moving the disks. The disks were attached to the onboard sata controller before I moved them. After the move I attached them to the SASUC8I controller. When I got problems I tried to attach them to the onboard controller again, but I still have problems. j...@opensolaris:~$ zpool status pool: vault state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scrub: none requested config: NAMESTATE READ WRITE CKSUM vault UNAVAIL 0 0 0 insufficient replicas raidz1-0 UNAVAIL 0 0 0 insufficient replicas c12d1 UNAVAIL 0 0 0 cannot open c12d0 UNAVAIL 0 0 0 cannot open c10d1 UNAVAIL 0 0 0 cannot open c11d0 UNAVAIL 0 0 0 cannot open logs c10d0p1 ONLINE 0 0 0 j...@opensolaris:~$ pfexec zpool import vault cannot import 'vault': a pool with that name is already created/imported, and no additional pools with that name were found j...@opensolaris:~$ pfexec zpool export vault cannot open 'vault': I/O error j...@opensolaris:~$ pfexec format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c8d0 /p...@0,0/pci-...@14,1/i...@0/c...@0,0 1. c10d0 /p...@0,0/pci-...@11/i...@0/c...@0,0 2. c13t0d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@0,0 3. c13t1d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@1,0 4. c13t2d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@2,0 5. c13t3d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@3,0 6. c13t4d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@4,0 7. c13t5d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@5,0 8. c13t6d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@6,0 9. c13t7d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@7,0 Specify disk (enter its number): ^C (0 is the boot drive, 1 is a OCZ SSD, 2-5 is the mirrored pool, 6-9 is the problem pool) j...@opensolaris:~$ cfgadm Ap_Id Type Receptacle Occupant Condition c13scsi-sas connectedconfigured unknown usb5/1 unknown emptyunconfigured ok ... j...@opensolaris:~$ zpool status cannot see the pool j...@opensolaris:~$ pfexec zpool import vault cannot import 'vault': one or more devices is currently unavailable Destroy and re-create the pool from a backup source. j...@opensolaris:~$ pfexec poweroff moved the disks back to the original controller j...@opensolaris:~$ pfexec zpool import vault cannot import 'vault': one or more devices is currently unavailable Destroy and re-create the pool from a backup source. j...@opensolaris:~$ pfexec format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c8d0 /p...@0,0/pci-...@14,1/i...@0/c...@0,0 1. c10d0 /p...@0,0/pci-...@11/i...@0/c...@0,0 2. c10d1 /p...@0,0/pci-...@11/i...@0/c...@1,0 3. c11d0 /p...@0,0/pci-...@11/i...@1/c...@0,0 4. c12d0 /p...@0,0/pci-...@14,1/i...@1/c...@0,0 5. c12d1 /p...@0,0/pci-...@14,1/i...@1/c...@1,0 6. c13t0d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@0,0 7. c13t1d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@1,0 8. c13t2d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@2,0 9. c13t3d0 /p...@0,0/pci1022,9...@2/pci1000,3...@0/s...@3,0 Specify disk (enter its number): ^C j...@opensolaris:~$ pfexec cfgadm -al Ap_Id Type Receptacle Occupant Condition c13scsi-sas connectedconfigured unknown c13::dsk/c13t0d0 disk connectedconfigured
Re: [zfs-discuss] Opteron 6100? Does it work with opensolaris?
Great! Please report here so we can read about your impressions. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
