Re: [zfs-discuss] zpool import of bootable root pool renders it
Hello David, Tuesday, September 30, 2008, 10:57:45 PM, you wrote: DF On Tue, 30 Sep 2008, Robert Milkowski wrote: Hello Juergen, Tuesday, September 30, 2008, 5:43:56 PM, you wrote: JN Stephen Quintero [EMAIL PROTECTED] writes: I am running OpenSolaris 2008.05 as a PV guest under Xen. If you import the bootable root pool of a VM into another Solaris VM, the root pool is no longer bootable. JN I had a similar problem: After installing and booting Opensolaris JN 2008.05, I succeded to lock myself out through some passwd/shadow JN inconsistency (totally my own fault). Not a problem, I thought -- I JN booted from the install disk, imported the root pool, fixed the JN inconsistency, and rebooted. Lo, instant panic. JN No idea why, though, I am not that familiar with the underlying JN code. I just did a reinstall. I hit the same issue - once I tried to boot OS from within virtualbox with disk partition exposed to VB - kernel couldn't mount root fs either from VB or directly from notebook - I had to import/export pool while booting from CD. I haven't investigated it further but I'm surprised it's not working OOB. DF I think this is 6737463 By quickly looking at stack trace IIIRC mine was different - actually it didn't panicked it couldn't mount rootfs and rebooted. Basically what I did - I has a working OS (b96 IIRC) along with Windows on my notebook. Both systems were booting properly. I installed VB on Windows and created a VM with a Solaris partition exposed as a raw device - VB showed me Grub I chose OS and it failed on mounting rootfs. After Windows reboot I couldn't boot into OS (from HW not VB). I booted from LiveCD, imported the pool, exported, rebooted again and now it booted fine from bare metal - haven't tried from VB again. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS Boot on SAN
Hi, are there any issue in ZFS boot using a pool with devices in a Storage Area Network (SAN)? I'm interested in both the SPARC and x86 platforms. Rgrds, Danilo. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
Marc Bevand m.bevand at gmail.com writes: Well let's look at a concrete example: - cheapest 15k SAS drive (73GB): $180 [1] - cheapest 7.2k SATA drive (160GB): $40 [2] (not counting a 80GB at $37) The SAS drive most likely offers 2x-3x the IOPS/$. Certainly not 180/40=4.5x Doh! I said the opposite of what I meant. Let me rephrase: The SAS drive offers at most 2x-3x the IOPS (optimistic), but at 180/40=4.5x the price. Therefore the SATA drive has better IOPS/$. (Joerg: I am on your side of the debate !) -marc ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] one step forward - pinging Lukas pool: ztankKarwacki (kangurek)
When I attempt again to import using zdb -e ztank I still get zdb: can't open ztank: I/O error and zpool import -f, whilst it starts and seems to access the disks sequentially, it stops al the 3rd one (no sure which precisely - it spins it up and the process stops right there, and the system will not reboot when asked to (shutdown -g0 -y -i5) so there's some slight progress here. How about just removing that disk and try importing? -- 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] Quantifying ZFS reliability
On Thu, 2 Oct 2008, Joerg Schilling wrote: I am not going to accept blanket numbers... If you claim that a 15k drive offers more than 2x the IOPS/s of a 7.2k drive you would need to show your computation. SAS and SATA use the same cable and in case you buy server grade SATA disks, you also get tagged command queuing. I sense some confusion here on your part related to basic physics. Even with identical seek times, if the drive spins 2X as fast then it is able to return the data in 1/2 the time already. But the best SAS drives have seek times 2-3X faster than SATA drives. In order to return data, the drive has to seek the head, and then wait for the data to start to arrive, which is entirely dependent on rotation rate. These are reasons why enterprise SAS drives offer far more IOPS than SATA drives. For 10 TB you need ~ 165 73 GB SAS drives - ~ 22000 Euro 2475 Watt stand by ~ 4 GBytes/s sustained read if you are lucky and have a good controller Max IOPS - 34000 (not realistic) I am not sure where you get the idea that 34000 is not realistic. It is perfectly in line with the performance I have measured with my own 12 drive array. As I mentioned yesterday, proper design isolates storage which requires maximum IOPS from storage which requires maximum storage capacity or lowest cost. Therefore, it is entirely pointless to discuss how many 73GB SAS drives are required to achieve 10TB of storage since this thinking almost always represents poor design. Bob == Bob Friesenhahn [EMAIL PROTECTED], 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] Quantifying ZFS reliability
On Thu, 2 Oct 2008, Marc Bevand wrote: Doh! I said the opposite of what I meant. Let me rephrase: The SAS drive offers at most 2x-3x the IOPS (optimistic), but at 180/40=4.5x the price. Therefore the SATA drive has better IOPS/$. I doubt that anyone will successfully argue that SAS drives offer the best IOPS/$ value as long as space, power, and reliability factors may be ignored. However, these sort of enterprise devices exist in order to allow enterprises to meet critical business demands which are otherwise not possible to be met. There are situations where space, power, and cooling are limited and the cost of the equipment is less of an issue since the space, power, and cooling cost more than the equipment. Bob == Bob Friesenhahn [EMAIL PROTECTED], 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] Quantifying ZFS reliability
Thanks for the info. I am not really after big performance, I am already on SATA and it's good enough for me. What I really really can't afford is data loss. The CAD designs our engineers are working on can sometimes be really worth a lot. But still we're a small company and would rather save and buy SATA drives if it is Safe I now understand MTBF is next to useless (at least directly), the RAID optimizer tables don't take how failure rates go up with years, so it's not really accurate. My question now is if I will use high quality Barracuda nearline 1TB sata 7200 disks, and configure them as 8 disks in a raidz2 configuration. What is the real/practical possibility that I will face data loss during the next 5 years for example ? As storage experts please help me interpret whatever numbers you're going to throw, so is it a really really small chance, or would you be worried about it ? Thanks On Thu, Oct 2, 2008 at 12:24 PM, Marc Bevand [EMAIL PROTECTED] wrote: Marc Bevand m.bevand at gmail.com writes: Well let's look at a concrete example: - cheapest 15k SAS drive (73GB): $180 [1] - cheapest 7.2k SATA drive (160GB): $40 [2] (not counting a 80GB at $37) The SAS drive most likely offers 2x-3x the IOPS/$. Certainly not 180/40=4.5x Doh! I said the opposite of what I meant. Let me rephrase: The SAS drive offers at most 2x-3x the IOPS (optimistic), but at 180/40=4.5x the price. Therefore the SATA drive has better IOPS/$. (Joerg: I am on your side of the debate !) -marc ___ 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] Terrible performance when setting zfs_arc_max snv_98
Hi there. I just got a new Adaptec RAID 51645 controller in because the old (other type) was malfunctioning. It is paired with 16 Seagate 15k5 disks, of which two are used with hardware RAID 1 for OpenSolaris snv_98, and the rest is configured as striped mirrors as a zpool. I created a zfs filesystem on this pool with a blocksize of 8K. This server has 64GB of memory and will be running postgreSQL, so we need to cut down ARC memory usage. But before I do this I tested the zfs performance using iometer (it was a bit tricky getting it to compile but it's running). So far so good. Figures look very promissing, with stagering random read and write figures! There are just a few problems: every few seconds, disk LED's stop working for a few seconds, except one disk at a time. When this cycle is finished, it looks normal again. This seems to be the flushing of the NVRAM cache. Should be solved by disabling the flush...So far so good... But I also need the memory for PostgreSQL to work, so I added: set zfs:zfs_arc_max=8589934592 to /etc/system and rebooted. Now redid my test, with terrible results.. sequential read is about 120 MB/sec. One disk should be able to handle that, 14 disks should do more than a GB/sec, and in my previous benchmark without the arc_max setting, they actually make these figures...(even when not reading from ARC cache). Random figures are not much better than this. So something is clearly wrong here... Can anyone comment? -- 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] Quantifying ZFS reliability
Bob Friesenhahn [EMAIL PROTECTED] wrote: On Thu, 2 Oct 2008, Joerg Schilling wrote: I am not going to accept blanket numbers... If you claim that a 15k drive offers more than 2x the IOPS/s of a 7.2k drive you would need to show your computation. SAS and SATA use the same cable and in case you buy server grade SATA disks, you also get tagged command queuing. I sense some confusion here on your part related to basic physics. Even with identical seek times, if the drive spins 2X as fast then it is able to return the data in 1/2 the time already. But the best SAS drives have seek times 2-3X faster than SATA drives. In order to return data, the drive has to seek the head, and then wait for the data to start to arrive, which is entirely dependent on rotation rate. These are reasons why enterprise SAS drives offer far more IOPS than SATA drives. You seem to missunderstand drive physics. With modern drives, seek times are not a dominating factor. It is the latency time that is rather important and this is indeed 1/rotanilnal-speed. On the other side you did missunderstand another important fact in drive physics: The sustained transfer speed of a drive is proportional to the linear data density on the medium. The third mistake you make is to see that confuse the effects from the drive interface type with the effects from different drive geometry. The only coincidence here is that the drive geometry is typically updated more frequently for SATA drives than it is for SAS drives. This way, you benefit from the higher data density of a recent SATA drive and get a higher sustained data rate. BTW: I am not saying it makes no sense to buy SAS drives but it makes sense to look at _all_ important parameters. Power consumption is a really important issue here and the reduced MTBF from using more disks is another one. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Oracle DB sequential dump questions
I would look at what size IOs you are doing in each case. I have been playing with a T5240 and got 400Mb/s read and 200Mb/s write speeds with iozone throughput tests on a 6 disk mirror pool, so the box and ZFS can certainly push data around - but that was using 128k blocks. You mention the disks are doing bursts of 50-60M which suggests they have more bandwidth and are not flat out trying to prefetch data. I suspect you might be IOPS bound - if you are doing a serial read then write workload and only doing small blocks to the tape it might lead to higher service times on the tape device hence slowing down your overall read speed. It its LTO-4 try and up your block size as big as you can go - 256k, 512k or higher and maybe use truss on the process to see what read/write sizes its doing. I also found the iosnoop dtrace tool from Brendan Greg's dtrace toolkit to be very helpful in tracking down these sorts of issues. HTH. Cheers, Adrian -- 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] Quantifying ZFS reliability
On Thu, 2 Oct 2008, Ahmed Kamal wrote: What is the real/practical possibility that I will face data loss during the next 5 years for example ? As storage experts please help me interpret whatever numbers you're going to throw, so is it a really really small chance, or would you be worried about it ? No one can tell you the answer to this. Certainly math can be formulated which shows that the pyramids in Egypt will be completely flattened before you experience data loss. Obviously that math has little value once it exceeds the lifetime of the computer by many orders of magnitude. Raidz2 is about as good as it gets on paper. Bad things can still happen which are unrelated to what raidz2 protects against or are a calamity which impacts all the hardware in the system. If you care about your data, make sure that you have a working backup system. Bob == Bob Friesenhahn [EMAIL PROTECTED], 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] Oracle DB sequential dump questions
Ta on the comments I'm going to use Jorg's 'star' to simulate some sequential backup workloads, using different blocksizes and see what the system do. I'll save some output and post for people that might match the same config, now or in the future. To be clear though: (currently) #tar cvfE /dev/rmt/0cbn /tmp/foobar (42 MB/s to tape sustained, 70% util on tape device) #tar cvfE /dev/rmt/0cbn /oracle/datafiles/* ( 24 MB/s to tape sustained, 24-60 MB/s zfs fs bursts) I'll post the star, iostat and other findings later. -- 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] Quantifying ZFS reliability
On Thu, Oct 2, 2008 at 11:43 AM, Joerg Schilling [EMAIL PROTECTED] wrote: You seem to missunderstand drive physics. With modern drives, seek times are not a dominating factor. It is the latency time that is rather important and this is indeed 1/rotanilnal-speed. On the other side you did missunderstand another important fact in drive physics: The sustained transfer speed of a drive is proportional to the linear data density on the medium. The third mistake you make is to see that confuse the effects from the drive interface type with the effects from different drive geometry. The only coincidence here is that the drive geometry is typically updated more frequently for SATA drives than it is for SAS drives. This way, you benefit from the higher data density of a recent SATA drive and get a higher sustained data rate. BTW: I am not saying it makes no sense to buy SAS drives but it makes sense to look at _all_ important parameters. Power consumption is a really important issue here and the reduced MTBF from using more disks is another one. Jörg -- Please, give me a list of enterprises currently using SATA drives for their database workloads, vmware workloads... hell any workload besides email archiving, lightly used cifs shares, or streaming sequential transfers of large files. I'm glad you can sit there with a spec sheet and tell me how you think things are going to work. I can tell you from real-life experience you're not even remotely correct in your assumptions. --Tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
On Thu, Oct 2, 2008 at 10:56 AM, Bob Friesenhahn [EMAIL PROTECTED] wrote: I doubt that anyone will successfully argue that SAS drives offer the best IOPS/$ value as long as space, power, and reliability factors may be ignored. However, these sort of enterprise devices exist in order to allow enterprises to meet critical business demands which are otherwise not possible to be met. There are situations where space, power, and cooling are limited and the cost of the equipment is less of an issue since the space, power, and cooling cost more than the equipment. Bob It's called USABLE IOPS/$. You can throw 500 drives at a workload, if you're attempting to access lots of small files in random ways, it won't make a lick of difference. --Tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
On Thu, Oct 2, 2008 at 3:09 AM, Marc Bevand [EMAIL PROTECTED] wrote: Erik Trimble Erik.Trimble at Sun.COM writes: Marc Bevand wrote: 7500rpm (SATA) drives clearly provide the best TB/$, throughput/$, IOPS/$. You can't argue against that. To paraphrase what was said earlier in this thread, to get the best IOPS out of $1000, spend your money on 10 7500rpm (SATA) drives instead of 3 or 4 15000rpm (SAS) drives. Similarly, for the best IOPS/RU, 15000rpm drives have the advantage. Etc. Be very careful about that. 73GB SAS drives aren't that expensive, so you can get 6 x 73GB 15k SAS drives for the same amount as 11 x 250GB SATA drives (per Sun list pricing for J4200 drives). SATA doesn't always win the IOPS/$. Remember, a SAS drive can provide more than 2x the number of IOPs a SATA drive can. Well let's look at a concrete example: - cheapest 15k SAS drive (73GB): $180 [1] - cheapest 7.2k SATA drive (160GB): $40 [2] (not counting a 80GB at $37) The SAS drive most likely offers 2x-3x the IOPS/$. Certainly not 180/40=4.5x [1] http://www.newegg.com/Product/Product.aspx?Item=N82E16822116057 [2] http://www.newegg.com/Product/Product.aspx?Item=N82E16822136075 But Marc - that scenario is not realistic. Your budget drives won't come with a 5 year warranty and the MTBF to go along with this warranty. To level the playing field lets narrow it down to: a) drives with a 5 year warranty b) drives that are designed for continuous 7x24 operation In the case of SATA drives, the Western Digital RE series and Seagate ES immediately spring to mind. Another very interesting SATA product is the WD Velociraptor - which blurs the line between 7k2 SATA and 15k RPM SAS drives. For the application the OP talked about, I doubt that he is going to run out and purchase low-cost drives that are more at home is a low-end desktop than they are in a ZFS based filesystem. Regards, -- Al Hopper Logical Approach Inc,Plano,TX [EMAIL PROTECTED] Voice: 972.379.2133 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
On Thu, Oct 2, 2008 at 12:46 PM, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Thu, 2 Oct 2008, Ahmed Kamal wrote: What is the real/practical possibility that I will face data loss during the next 5 years for example ? As storage experts please help me interpret whatever numbers you're going to throw, so is it a really really small chance, or would you be worried about it ? No one can tell you the answer to this. Certainly math can be formulated which shows that the pyramids in Egypt will be completely flattened before you experience data loss. Obviously that math has little value once it exceeds the lifetime of the computer by many orders of magnitude. Raidz2 is about as good as it gets on paper. Bad things can still happen which are unrelated to what raidz2 protects against or are a calamity which impacts all the hardware in the system. If you care about your data, make sure that you have a working backup system. Agreed. But make that an offsite backup (Amazon S3 comes to mind). We are already at the point in the evolution of computer technology where errors caused by people are far more likely to cause data loss. Or a water leak over the weekend or etc. Regards, -- Al Hopper Logical Approach Inc,Plano,TX [EMAIL PROTECTED] Voice: 972.379.2133 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
On Thu, Oct 02, 2008 at 12:46:59PM -0500, Bob Friesenhahn wrote: On Thu, 2 Oct 2008, Ahmed Kamal wrote: What is the real/practical possibility that I will face data loss during the next 5 years for example ? As storage experts please help me interpret whatever numbers you're going to throw, so is it a really really small chance, or would you be worried about it ? No one can tell you the answer to this. Certainly math can be formulated which shows that the pyramids in Egypt will be completely flattened before you experience data loss. Obviously that math has little value once it exceeds the lifetime of the computer by many orders of magnitude. Raidz2 is about as good as it gets on paper. Bad things can still happen which are unrelated to what raidz2 protects against or are a calamity which impacts all the hardware in the system. If you care about your data, make sure that you have a working backup system. Bad things like getting all your drives from a bad drive batch, so they all fail near simultaneously and much sooner than you'd expect. As always, do backup your data. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool import of bootable root pool renders it unbootable
I came across this bug in a similar way myself. The explanation given by Stephen Hahn is this: -- For a while, the boot-archive on 2008.nn systems included a copy of zpool.cache. Recent versions do not make this mistake. Delete and regenerate your boot archive, and you should be able to make the transfer. See http://mail.opensolaris.org/pipermail/indiana-discuss/2008-August/008341.html and following. --- If you install a system from scratch with the latest test build of OpenSolaris 2008.11 (which you can get from genunix.org) then you won't have this problem. Solaris Express Community Edition (SXCE) is also not affected by this bug. Cheers Andrew. -- 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] Quantifying ZFS reliability
OK, we cut off this thread now. Bottom line here is that when it comes to making statements about SATA vs SAS, there are ONLY two statements which are currently absolute: (1) a SATA drive has better GB/$ than a SAS drive (2) a SAS drive has better throughput and IOPs than a SATA drive This is comparing apples to apples (that is, drives in the same generation, available at the same time): ANY OTHER RANKING depends on your prioritization of cost, serviceability (i.e. vendor support), throughput, IOPS, space, power, and redundancy. When we have this discussion, PLEASE, folks, ASK SPECIFICALLY ABOUT YOUR CONFIGURATION - that is, to those asking the initial question, SPECIFY your ranking of the above criteria. Otherwise, to all those on this list, DON'T ANSWER - we constantly devolve into tit-for-tat otherwise. That's it, folks. -Erik On Thu, 2008-10-02 at 13:39 -0500, Tim wrote: On Thu, Oct 2, 2008 at 11:43 AM, Joerg Schilling [EMAIL PROTECTED] wrote: You seem to missunderstand drive physics. With modern drives, seek times are not a dominating factor. It is the latency time that is rather important and this is indeed 1/rotanilnal-speed. On the other side you did missunderstand another important fact in drive physics: The sustained transfer speed of a drive is proportional to the linear data density on the medium. The third mistake you make is to see that confuse the effects from the drive interface type with the effects from different drive geometry. The only coincidence here is that the drive geometry is typically updated more frequently for SATA drives than it is for SAS drives. This way, you benefit from the higher data density of a recent SATA drive and get a higher sustained data rate. BTW: I am not saying it makes no sense to buy SAS drives but it makes sense to look at _all_ important parameters. Power consumption is a really important issue here and the reduced MTBF from using more disks is another one. Jörg -- Please, give me a list of enterprises currently using SATA drives for their database workloads, vmware workloads... hell any workload besides email archiving, lightly used cifs shares, or streaming sequential transfers of large files. I'm glad you can sit there with a spec sheet and tell me how you think things are going to work. I can tell you from real-life experience you're not even remotely correct in your assumptions. --Tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- 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] Oracle DB sequential dump questions
Louwtjie Burger [EMAIL PROTECTED] wrote: Ta on the comments I'm going to use Jorg's 'star' to simulate some sequential backup workloads, using different blocksizes and see what the system do. I'll save some output and post for people that might match the same config, now or in the future. To be clear though: (currently) #tar cvfE /dev/rmt/0cbn /tmp/foobar (42 MB/s to tape sustained, 70% util on tape device) #tar cvfE /dev/rmt/0cbn /oracle/datafiles/* ( 24 MB/s to tape sustained, 24-60 MB/s zfs fs bursts) I'll post the star, iostat and other findings later. If you have plenty of RAM and if you see that the tape is not streaming with star, give star plenty of FIFO size. If the tape drive supports 60 MB/s, give star 1800 MB for the FIFo (fs=1800m) in case that your physical RAM is at least 4 GB. This gives star 30 seconds reserve data for keeping the tape streaming. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] one step forward - pinging Lukas pool: ztankKarwacki (kangurek)
Thanks Martin, Yeah, tried it but no luck :-( I do not think it is a hardware problem - in fact I tried removing every disk one by one with no luck - this is why I think it is not in fact a hardware problem... Kind regards Vasile -- 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] Quantifying ZFS reliability
Erik Trimble Erik.Trimble at Sun.COM writes: Bottom line here is that when it comes to making statements about SATA vs SAS, there are ONLY two statements which are currently absolute: (1) a SATA drive has better GB/$ than a SAS drive (2) a SAS drive has better throughput and IOPs than a SATA drive Yes, and to represent statements (1) and (2) in a more exhaustive table: Best X per Y | Dollar Watt Rack Unit (or per drive) ---+--- Capacity | SATA(1) SATA SATA Throughput | SATA SASSAS(2) IOPS | SATA SASSAS(2) If (a) people understood that each of these 9 performance numbers can be measured independently from each other, and (b) knew which of these numbers matter for a given workload (very often multiple of them do, so a compromise has to be made), then there would be no more circular SATA vs. SAS debates. -marc ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quantifying ZFS reliability
I hate to drag this thread on, but... Erik Trimble wrote: OK, we cut off this thread now. Bottom line here is that when it comes to making statements about SATA vs SAS, there are ONLY two statements which are currently absolute: (1) a SATA drive has better GB/$ than a SAS drive In general, yes. (2) a SAS drive has better throughput and IOPs than a SATA drive Disagree. We proved that the transport layer protocol has no bearing on throughput or iops. Several vendors offer drives which are identical in all respects except for transport layer protocol: SAS or SATA. You can choose either transport layer protocol and the performance remains the same. This is comparing apples to apples (that is, drives in the same generation, available at the same time): Add same size. One common mis-correlation in this thread is comparing 3.5 SATA disks against 2.5 SAS disks -- there is a big difference in the capacity, power consumption, and seek time as the disk diameter changes. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
