Re: [zfs-discuss] Oracle releases Solaris 11 for Sparc and x86 servers
> > ... so when will zfs-related improvement make it to solaris- > derivatives :D ? > I am also very curious about Oracle's policy about source code. ;-) Fred ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Oracle releases Solaris 11 for Sparc and x86 servers
On Thu, Nov 10, 2011 at 6:54 AM, Fred Liu wrote: > ... so when will zfs-related improvement make it to solaris-derivatives :D ? -- FAN ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] how to set up solaris os and cache within one SSD
2011/11/10 Jeff Savit > ** > Hi darkblue, comments in-line > > > On 11/09/2011 06:11 PM, darkblue wrote: > > hi, all > I am a newbie on ZFS, recently, my company is planning to build a > entry-level enterpirse storage server. > here is the hardware list: > > 1 * XEON 5606 > 1 * supermirco X8DT3-LN4F > 6 * 4G RECC RAM > 22 * WD RE3 1T harddisk > 4 * intel 320 (160G) SSD > 1 * supermicro 846E1-900B chassis > > this storage is going to serve: > 1、100+ VMware and xen guest > 2、backup storage > > my original plan is: > 1、create a mirror root within a pair of SSD, then partition one the them > for cache (L2ARC), Is this reasonable? > > Why would you want your root pool to be on the SSD? Do you expect an > extremely high I/O rate for the OS disks? Also, not a good idea for > performance to partition the disks as you suggest. > > because the solaris os occuppied the whole 1TB disk is a waste and the RAM is only 24G, does this could handle such big cache（160G）? 2、the other pair of SSD will be used for ZIL How about using 1 pair of SSD for ZIL, and the other pair of SSD for L2ARC > > > 3、I haven't got a clear scheme for the 22 WD disks. > > I suggest a mirrored pool on the WD disks for a root ZFS pool, and the > other 20 disks for a data pool (quite possibly also a mirror) that also > incorporates the 4 SSD, using 2 each for ZIL and L2ARC. If you want to > isolate different groups of virtual disks then you could have other > possibilities. Maybe split the 20 disks between guest virtual disks and a > backup pool. Lots of possibilities. > > hmm, could you give me an example and more details info suppose after mirror 20 hard disk, we got a 10TB usage space, and 6TB will be use for Vguest, 4TB will be use for backup purpose. within 6TB space，3TB might throught iSCSI to XEN domU, the other 3TB might throught NFS to VMware guest. 4TB might throught NFS for backup. thanks in advanced. > > any suggestion? > especially how to get No 1 step done? > > Creating the mirrored root pool is easy enough and install time - just > save the SSD for the guest virtual disks. All of this is in absence of the > actual performance characteristics you expect, but that's a reasonable > starting point. > > I hope that's useful... Jeff > That is great, thanks Jeff > > -- > > > *Jeff Savit* | Principal Sales Consultant > Phone: 602.824.6275 | Email: jeff.sa...@oracle.com | Blog: > http://blogs.oracle.com/jsavit > Oracle North America Commercial Hardware > Operating Environments & Infrastructure S/W Pillar > 2355 E Camelback Rd | Phoenix, AZ 85016 > > > > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] how to set up solaris os and cache within one SSD
Hi darkblue, comments in-line On 11/09/2011 06:11 PM, darkblue wrote: hi, all I am a newbie on ZFS, recently, my company is planning to build a entry-level enterpirse storage server. here is the hardware list: 1 * XEON 5606 1 * supermirco X8DT3-LN4F 6 * 4G RECC RAM 22 * WD RE3 1T harddisk 4 * intel 320 (160G) SSD 1 * supermicro 846E1-900B chassis this storage is going to serve: 1、100+ VMware and xen guest 2、backup storage my original plan is: 1、create a mirror root within a pair of SSD, then partition one the them for cache (L2ARC), Is this reasonable? Why would you want your root pool to be on the SSD? Do you expect an extremely high I/O rate for the OS disks? Also, not a good idea for performance to partition the disks as you suggest. 2、the other pair of SSD will be used for ZIL How about using 1 pair of SSD for ZIL, and the other pair of SSD for L2ARC 3、I haven't got a clear scheme for the 22 WD disks. I suggest a mirrored pool on the WD disks for a root ZFS pool, and the other 20 disks for a data pool (quite possibly also a mirror) that also incorporates the 4 SSD, using 2 each for ZIL and L2ARC. If you want to isolate different groups of virtual disks then you could have other possibilities. Maybe split the 20 disks between guest virtual disks and a backup pool. Lots of possibilities. any suggestion? especially how to get No 1 step done? Creating the mirrored root pool is easy enough and install time - just save the SSD for the guest virtual disks. All of this is in absence of the actual performance characteristics you expect, but that's a reasonable starting point. I hope that's useful... Jeff -- *Jeff Savit* | Principal Sales Consultant Phone: 602.824.6275 | Email: jeff.sa...@oracle.com | Blog: http://blogs.oracle.com/jsavit Oracle North America Commercial Hardware Operating Environments & Infrastructure S/W Pillar 2355 E Camelback Rd | Phoenix, AZ 85016 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Couple of questions about ZFS on laptops
Some laptops have pc card and expresscard slots, and you can get an adapter for sd card, so you could set up your os non mirrored and just set up home on a pair of sd cards. Something like http://www.amazon.com/Sandisk-SDAD109A11-Digital-Card-Express/dp/B000W3QLLW I've done this in the past, variations of this, including using a partition and a usb stick: http://solarisdesktop.blogspot.com/2007/02/stick-to-zfs-or-laptop-with-mirrored.html Wow, where did the time go, that was almost 5 years ago... Anyway, i pretty much ditched carrying the laptop, the current one i have is too heavy (m4400). But it does run really nicely sol11 and openindiana. The m4400 is set up with 2 drives, not mirrored. I'm tempted to put a sandforce based ssd for faster booting and better zfs perf for demos. Then i have an sdcard and expresscard adapter for sd. This gives me 16gb mirrored for my documents, which is plenty. Francois Sent from my iPad On Nov 8, 2011, at 12:05 PM, Jim Klimov wrote: > Hello all, > > I am thinking about a new laptop. I see that there are > a number of higher-performance models (incidenatlly, they > are also marketed as "gamer" ones) which offer two SATA > 2.5" bays and an SD flash card slot. Vendors usually > position the two-HDD bay part as either "get lots of > capacity with RAID0 over two HDDs, or get some capacity > and some performance by mixing one HDD with one SSD". > Some vendors go as far as suggesting a highest performance > with RAID0 over two SSDs. > > Now, if I were to use this for work with ZFS on an > OpenSolaris-descendant OS, and I like my data enough > to want it mirrored, but still I want an SSD performance > boost (i.e. to run VMs in real-time), I seem to have > a number of options: > > 1) Use a ZFS mirror of two SSDs > - seems too pricey > 2) Use a HDD with redundant data (copies=2 or mirroring > over two partitions), and an SSD for L2ARC (+maybe ZIL) > - possible unreliability if the only HDD breaks > 3) Use a ZFS mirror of two HDDs > - lowest performance > 4) Use a ZFS mirror of two HDDs and an SD card for L2ARC. > Perhaps add another "built-in flash card" with PCMCIA > adapters for CF, etc. > > Now, there is a couple of question points for me here. > > One was raised in my recent questions about CF ports in a > Thumper. The general reply was that even high-performance > CF cards are aimed for "linear" RW patterns and may be > slower than HDDs for random access needed as L2ARCs, so > flash cards may actually lower the system performance. > I wonder if the same is the case with SD cards, and/or > if anyone encountered (and can advise) some CF/SD cards > with good random access performance (better than HDD > random IOPS). Perhaps an extra IO path can be beneficial > even if random performances are on the same scale - HDDs > would have less work anyway and can perform better with > their other tasks? > > On another hand, how would current ZFS behave if someone > ejects an L2ARC device (flash card) and replaces it with > another unsuspecting card, i.e. one from a photo camera? > Would ZFS automatically replace the L2ARC device and > kill the photos, or would the cache be disabled with > no fatal implication for the pools nor for the other > card? Ultimately, when the ex-L2ARC card gets plugged > back in, would ZFS automagically attach it as the cache > device, or does this have to be done manually? > > > Second question regards single-HDD reliability: I can > do ZFS mirroring over two partitions/slices, or I can > configure "copies=2" for the datasets. Either way I > think I can get protection from bad blocks of whatever > nature, as long as the spindle spins. Can these two > methods be considered equivalent, or is one preferred > (and for what reason)? > > > Also, how do other list readers place and solve their > preferences with their OpenSolaris-based laptops? ;) > > Thanks, > //Jim Klimov > > ___ > 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] how to set up solaris os and cache within one SSD
hi, all I am a newbie on ZFS, recently, my company is planning to build a entry-level enterpirse storage server. here is the hardware list: 1 * XEON 5606 1 * supermirco X8DT3-LN4F 6 * 4G RECC RAM 22 * WD RE3 1T harddisk 4 * intel 320 (160G) SSD 1 * supermicro 846E1-900B chassis this storage is going to serve: 1、100+ VMware and xen guest 2、backup storage my original plan is: 1、create a mirror root within a pair of SSD, then partition one the them for cache (L2ARC), Is this reasonable? 2、the other pair of SSD will be used for ZIL 3、I haven't got a clear scheme for the 22 WD disks. any suggestion? especially how to get No 1 step done? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Oracle releases Solaris 11 for Sparc and x86 servers
___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs sync=disabled property
On Wed, November 9, 2011 10:35, Tomas Forsman wrote: > Too bad NFS is resilient against servers coming and going.. NFSv4 is statefull, so server reboots are more noticeable. (This has pluses and minuses.) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs sync=disabled property
On 08 November, 2011 - Edward Ned Harvey sent me these 2,9K bytes:
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Evaldas Auryla
> >
> > I'm trying to evaluate what are the risks of running NFS share of zfs
> > dataset with sync=disabled property. The clients are vmware hosts in our
> > environment and server is SunFire X4540 "Thor" system. Though general
> > recommendation tells not to do this, but after testing performance with
> > default setting and sync=disabled - it's night and day, so it's really
> > tempting to do sync=disabled ! Thanks for any suggestion.
>
> I know a lot of people will say "don't do it," but that's only partial
> truth. The real truth is:
>
> At all times, if there's a server crash, ZFS will come back along at next
> boot or mount, and the filesystem will be in a consistent state, that was
> indeed a valid state which the filesystem actually passed through at some
> moment in time. So as long as all the applications you're running can
> accept the possibility of "going back in time" as much as 30 sec, following
> an ungraceful ZFS crash, then it's safe to disable ZIL (set sync=disabled).
Client writes block 0, server says OK and writes it to disk.
Client writes block 1, server says OK and crashes before it's on disk.
Client writes block 2.. waaiits.. waiits.. server comes up and, server
says OK and writes it to disk.
Now, from the view of the clients, block 0-2 are all OK'd by the server
and no visible errors.
On the server, block 1 never arrived on disk and you've got silent
corruption.
Too bad NFS is resilient against servers coming and going..
/Tomas
--
Tomas Forsman, 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] Data distribution not even between vdevs
On 11/9/2011 8:05 AM, Edward Ned Harvey wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Ding Honghui But now, as show below, the first 2 raidz1 vdev usage is about 78% and the last 2 raidz1 vdev usage is about 93%. In this case, when you write, it should be writing to the first two vdevs, not the last two. So the fact that the last two are over 93% full should be irrelevant in terms of write performance. All my file is small files which size is about 150KB. That's too bad. Raidz performs well with large sequential data, and performs poor with small random files. Now the questions is: 1. Should I balance the data between the vdevs by copy the data and remove the data which locate in last 2 vdevs? If you want to. But most people wouldn't bother. Especially since you're talking about 75% versus 90%. It's difficult to balance it so *precisely* as to get them both around 85% 2. Is there any method to automatically re-balance the data? or There is no automatic way to do it. For me, this is a key issue. If there was an automatic rebalancing mechanism, that same mechanism would work perfectly to allow pools to have disk sets removed. It would provide the needed basic mechanism of just moving stuff around to eliminate the use of a particular part of the pool that you wanted to remove. Gregg Wonderly ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs sync=disabled property
On 11/ 9/11 03:11 PM, Edward Ned Harvey wrote: From: Evaldas Auryla [mailto:evaldas.aur...@edqm.eu] Sent: Wednesday, November 09, 2011 8:55 AM I was thinking about STEC ZeusRAM, but unfortunately it's SAS only device, and it won't make into X4540 (SATA ports only), so another option could be STEC MACH16iops (50GB SLC SATA SSD). Perhaps you should also consider ddrdrive I work a lot on flash... and I've got to say... dram is a lot faster. Mostly because of design/implementation limitations in the present controller technologies. Restrictions about which blocks can be erased and when, and how many erase in parallel, under which circumstances etc etc blah blah. That's mostly where any delay comes from. Straight out of the box, SSD's perform very well. But in real life, only moderately well. Yes, I was thinking about that, but X4540 "Thor"s have only low profile PCIe slots, and DDRdrive X1 requires full heigh slot, unfortunately. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs sync=disabled property
> From: Evaldas Auryla [mailto:evaldas.aur...@edqm.eu] > Sent: Wednesday, November 09, 2011 8:55 AM > > I was thinking about STEC ZeusRAM, but unfortunately it's SAS only > device, and it won't make into X4540 (SATA ports only), so another > option could be STEC MACH16iops (50GB SLC SATA SSD). Perhaps you should also consider ddrdrive I work a lot on flash... and I've got to say... dram is a lot faster. Mostly because of design/implementation limitations in the present controller technologies. Restrictions about which blocks can be erased and when, and how many erase in parallel, under which circumstances etc etc blah blah. That's mostly where any delay comes from. Straight out of the box, SSD's perform very well. But in real life, only moderately well. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Data distribution not even between vdevs
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Ding Honghui > > But now, as show below, the first 2 raidz1 vdev usage is about 78% and the > last 2 raidz1 vdev usage is about 93%. In this case, when you write, it should be writing to the first two vdevs, not the last two. So the fact that the last two are over 93% full should be irrelevant in terms of write performance. > All my file is small files which size is about 150KB. That's too bad. Raidz performs well with large sequential data, and performs poor with small random files. > Now the questions is: > 1. Should I balance the data between the vdevs by copy the data and remove > the data which locate in last 2 vdevs? If you want to. But most people wouldn't bother. Especially since you're talking about 75% versus 90%. It's difficult to balance it so *precisely* as to get them both around 85% > 2. Is there any method to automatically re-balance the data? > or There is no automatic way to do it. > Any better solution to resolve this problem? I would recommend, if possible, re-creating your pool as a bunch of mirrors instead of raidz. It will perform better, but it will cost hardware. Also, if you have compressible data then enabling compression gains both performance and available disk space. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs sync=disabled property
On 11/ 9/11 01:42 AM, Edward Ned Harvey wrote: I know a lot of people will say "don't do it," but that's only partial truth. The real truth is: At all times, if there's a server crash, ZFS will come back along at next boot or mount, and the filesystem will be in a consistent state, that was indeed a valid state which the filesystem actually passed through at some moment in time. So as long as all the applications you're running can accept the possibility of "going back in time" as much as 30 sec, following an ungraceful ZFS crash, then it's safe to disable ZIL (set sync=disabled). Ok, so the risk is about ZFS server unexpexted reboot (crash, power, hardware problem..). Long story short, if you're willing to allow your server and all of the dependent clients to go back in time as much as 30 seconds, and you're willing/able to reboot everything that depends on it, then you can accept the sync=disabled That's a lot of thinking. And a lot of faith or uncertainty. And in your case, it's kind of inconvenient. Needing to manually start your NFS share every time you reboot your ZFS server. Let's say assuming ZFS is stable (we never had problems on any opensolaris/openindiana systems, except ones with CIFS services enabled..), the server is running in well power-protected rack and on Sun's legendary reliable hardware (e.g. X4540), doing "sync=disabled" thing could be acceptable option for test lab environments. The safer/easier thing to do is add dedicated log devices to the server instead. It's not as fast as running with ZIL disabled, but it's much faster than running without a dedicated log. and for production use ZIL dedicated device is required. When choosing a log device, focus on FAST. You really don't care about size. Even 4G is usually all you need. I was thinking about STEC ZeusRAM, but unfortunately it's SAS only device, and it won't make into X4540 (SATA ports only), so another option could be STEC MACH16iops (50GB SLC SATA SSD). Thanks to all for sharing your ideas and suggestions. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
