Re: [zfs-discuss] AHCI or IDE?
AHCI or IDE is at the device level not zfs level, as such it's a property of the OS layer. I suspect all OSs that zfs run on support AHCI directly (OpenSolaris do). Always use it instead of IDE emulation (which is what is happening what you select IDE in the firmware, it is purely for old OS support with no direct SATA support) HTH, Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Alexander Lesle Sent: 16 December 2010 19:43 To: zfs-discuss@opensolaris.org Subject: [zfs-discuss] AHCI or IDE? Hello All, I want to build a home file and media server now. After experiment with a Asus Board and running in unsolve problems I have bought this Supermicro Board X8SIA-F with Intel i3-560 and 8 GB Ram http://www.supermicro.com/products/motherboard/Xeon3000/3400/X8SIA.cfm?IPMI= Y also the LSI HBA SAS 9211-8i http://lsi.com/storage_home/products_home/host_bus_adapters/sas_hbas/interna l/sas9211-8i/index.html rpool = 2vdev mirror tank = 2 x 2vdev mirror. For the future I want to have the option to expand up to 12 x 2vdev mirror. After reading the board manual I found at page 4-9 where I can set SATA#1 from IDE to AHCI. Can zfs handle AHCI for rpool? Can zfs handle AHCI for tank? Thx for helping. -- Regarrds Alexander ___ 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] A few questions
Hi, Which brings up an interesting question... IF it were fixed in for example illumos or freebsd is there a plan for how to handle possible incompatible zfs implementations? Currently the basic version numbering only works as it implies only one stream of development, now with multiple possible stream does ZFS need to move to a feature bit system or are we going to have to have forks or multiple incompatible versions? Thanks, Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Phil Harman Sent: 20 December 2010 10:43 To: Lanky Doodle Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] A few questions > Why does resilvering take so long in raidz anyway? Because it's broken. There were some changes a while back that made it more broken. There has been a lot of discussion, anecdotes and some data on this list. The resilver doesn't do a single pass of the drives, but uses a "smarter" temporal algorithm based on metadata. However, the current implentation has difficulty finishing the job if there's a steady flow of updates to the pool. As far as I'm aware, the only way to get bounded resilver times is to stop the workload until resilvering is completed. The problem exists for mirrors too, but is not as marked because mirror reconstruction is inherently simpler. I believe Oracle is aware of the problem, but most of the core ZFS team has left. And of course, a fix for Oracle Solaris no longer means a fix for the rest of us. ___ 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] A few questions
On Dec 20, 2010, at 7:31 AM, Phil Harman wrote: > If you only have a few slow drives, you don't have performance. > Like trying to win the Indianapolis 500 with a tricycle... Well you can put a jet engine on a tricycle and perhaps win it… Or you can change the race course to only allow a tricycle space to move. In the context of storage we have 2 factors hardware and software, having faster and more reliable spindles is no reason to suggest that better software can’t be used to beat it. The simple example is ZIL SSD, where using some software and even a cheap commodity SSD will outperform sync writes than any amount of expensive spindle drives. Before ZIL software is was easy to argue that the only way of speeding up writes was more faster spindles. The question therefore is, is there room in the software implementation to achieve performance and reliability numbers similar to expensive drives whilst using relative cheap drives? ZFS is good but IMHO easy to see how it can be improved to better meet this situation, I can’t currently say when this line of thinking and code will move from research to production level use (tho I have a pretty good idea ;) ) but I wouldn’t bet on the status quo lasting much longer. In some ways the removal of OpenSolaris may actually be a good thing, as its catalyized a number of developers from the view that zfs is Oracle led, to thinking “what can we do with zfs code as a base”? Ffor example how about sticking a cheap 80GiB commodity SSD in the storage case. When a resilver or defrag is required, use it as a scratch space to give you a block of fast IOPs storage space to accelerate the slow parts. When its done secure erase and power it down, ready for the next time a resilver needs to happen. The hardware is available, just needs someone to write the software… Bye, Deano ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] A few questions
Doh sorry about that, the threading got very confused on my mail reader! Bye, Deano From: Phil Harman [mailto:phil.har...@gmail.com] Sent: 21 December 2010 13:12 To: Deano Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] A few questions On 21/12/2010 13:05, Deano wrote: On Dec 20, 2010, at 7:31 AM, Phil Harman wrote: > If you only have a few slow drives, you don't have performance. > Like trying to win the Indianapolis 500 with a tricycle... Actually, I didn't say that, Richard did :) Well you can put a jet engine on a tricycle and perhaps win it… Or you can change the race course to only allow a tricycle space to move. In the context of storage we have 2 factors hardware and software, having faster and more reliable spindles is no reason to suggest that better software can’t be used to beat it. The simple example is ZIL SSD, where using some software and even a cheap commodity SSD will outperform sync writes than any amount of expensive spindle drives. Before ZIL software is was easy to argue that the only way of speeding up writes was more faster spindles. The question therefore is, is there room in the software implementation to achieve performance and reliability numbers similar to expensive drives whilst using relative cheap drives? ZFS is good but IMHO easy to see how it can be improved to better meet this situation, I can’t currently say when this line of thinking and code will move from research to production level use (tho I have a pretty good idea ;) ) but I wouldn’t bet on the status quo lasting much longer. In some ways the removal of OpenSolaris may actually be a good thing, as its catalyized a number of developers from the view that zfs is Oracle led, to thinking “what can we do with zfs code as a base”? Ffor example how about sticking a cheap 80GiB commodity SSD in the storage case. When a resilver or defrag is required, use it as a scratch space to give you a block of fast IOPs storage space to accelerate the slow parts. When its done secure erase and power it down, ready for the next time a resilver needs to happen. The hardware is available, just needs someone to write the software… Bye, Deano ___ 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] stupid ZFS question - floating point operations
There are no floating points operations in zfs, however even if there would that wouldn't be a bad thing, as modern CPU are float monsters indeed its likely some things would be faster if converted to use the float ALU (note however those operations would have to account for the different properties of the ALUs). The most complex ALU parts of zfs are the Galois field math in the RAID codes and the checksum operations. All of which are integer ops (tho it might be interesting to see if the Galois field could be accelerated using the float ALU). Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Jerry Kemp Sent: 22 December 2010 19:44 To: zfs-discuss@opensolaris.org Subject: [zfs-discuss] stupid ZFS question - floating point operations I have a coworker, who's primary expertise is in another flavor of Unix. This coworker lists floating point operations as one of ZFS detriments. I's not really sure what he means specifically, or where he got this reference from. In an effort to refute what I believe is an error or misunderstanding on his part, I have spent time on Yahoo, Google, the ZFS section of OpenSolaris.org, etc. I really haven't turned up much of anything that would prove or disprove his comments. The one thing I haven't done is to go through the ZFS source code, but its been years since I have done any serious programming. If someone from Oracle, or anyone on this mailing list could point me towards any documentation, or give me a definitive word, I would sure appreciate it. If there were floating point operations going on within ZFS, at this point I am uncertain as to what they would be. TIA for any comments, Jerry ___ 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] stupid ZFS question - floating point operations
-Original Message- From: Peter Jeremy [mailto:peter.jer...@alcatel-lucent.com] Sent: 22 December 2010 21:17 To: Deano Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] stupid ZFS question - floating point operations On 2010-Dec-23 04:48:19 +0800, Deano wrote: > modern CPU are float monsters indeed its likely some things would be >faster if converted to use the float ALU Peter wrote > _Some_ modern CPUs are good at FP, a lot aren't. The SPARC T-1 was particularly > poor as it only had a single FPU. Likewise, performance in the x86 world is highly > variable, depending on the vendor and core you pick. AFAIK, iA64 and PPC are > consistently good - but neither are commonly found in conjunction with ZFS. You > may also need to allow for software assist: Very few CPUs implement all of the > IEEE FP standard in hardware and most (including SPARC) require software to > implement parts of the standard. If your algorithm happens to make significant use > of things other than normalised numbers and zero, your performance may be severely > affected by the resultant traps and software assistance. I can't speak for old architecture like SPARC but all modern ALU designs support most of the subset of useful IEEE in hardware and at high speed. In particular x86 has extremely good float ALU performance, compared to some architectures it is relatively low but certainly not something to avoid. A CPU design that isn't at *least* 5 GFLOPS per core is archaic. This is only accelerating due to the consumer market that many CPUs end up in. From graphics to video decoding to audio synthesis, floating point math dominants. Not to say they aren't able to perform very many integer ALU ops as well, just that the old mantra that FPU is to be avoided hasn't been true for years. > Any use of floating point within the kernel also means changes to when FPU context > is saved - and, unless this can be implemented lazily, it will adversely impact the > cost of all context switches and potentially system calls. Of course the cost of the extra register movement involved in context switches is a concern, but this cost can be evaluated against the gains. I like to see someone actually profile the costs in SunOs as many kernel architectures I know accept FPU (and other specialist registers) restoration when needed as a worthwhile cost. Bye, Deano ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Looking for 3.5" SSD for ZIL
If anybody does know of any source to the secure erase/reformatters, I'll happily volunteer to do the port and then maintain it. I'm currently in talks with several SSD and driver chip hardware peeps with regard getting datasheets for some SSD products etc. for the purpose of better support under the OI/Solaris driver model but these things can take a while to obtain, so if anybody knows of existing open source versions I'll jump on it. Thanks, Deano From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Garrett D'Amore Sent: 23 December 2010 15:22 To: Erik Trimble; Christopher George Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] Looking for 3.5" SSD for ZIL We should get the reformatter(s) ported to illumos/solaris, if source is available. Something to consider. - Garrett -Original Message- From: zfs-discuss-boun...@opensolaris.org on behalf of Erik Trimble Sent: Wed 12/22/2010 10:36 PM To: Christopher George Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] Looking for 3.5" SSD for ZIL On 12/22/2010 7:05 AM, Christopher George wrote: >> I'm not sure if TRIM will work with ZFS. > Neither ZFS nor the ZIL code in particular support TRIM. > >> I was concerned that with trim support the SSD life and >> write throughput will get affected. > Your concerns about sustainable write performance (IOPS) > for a Flash based SSD are valid, the resulting degradation > will vary depending on the controller used. > > Best regards, > > Christopher George > Founder/CTO > www.ddrdrive.com Christopher is correct, in that SSDs will suffer from (non-trivial) performance degredation after they've exhausted their free list, and haven't been told to reclaim emptied space. True battery-backed DRAM is the only permanent solution currently available which never runs into this problem. Even TRIM-supported SSDs eventually need reconditioning. However, this *can* be overcome by frequently re-formatting the SSD (not the Solaris format, a low-level format using a vendor-supplied utility). It's generally a simple thing, but requires pulling the SSD from the server, connecting it to either a Linux or Windows box, running the reformatter, then replacing the SSD. Which, is a PITA. But, still a bit cheaper than buying a DDRdrive. -- 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Looking for 3.5" SSD for ZIL
In an ideal world, if we could obtain details on how to reset/format blocks of a SSD, we could do it automatically running behind the ZIL. As a log its going in one direction, a background task could clean up behind it, making the performance lowing over time a non-issue for the ZIL. A first start may be calling unmap/trim on those blocks (which I was surprised to find in the source is already coded up in the SATA driver, just not used yet) but really a reset would be better. But as you say a tool to say if its need doing would be a good start. They certainly exist in closed source form... Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Ray Van Dolson Sent: 23 December 2010 15:46 To: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] Looking for 3.5" SSD for ZIL On Thu, Dec 23, 2010 at 07:35:29AM -0800, Deano wrote: > If anybody does know of any source to the secure erase/reformatters, > I’ll happily volunteer to do the port and then maintain it. > > I’m currently in talks with several SSD and driver chip hardware > peeps with regard getting datasheets for some SSD products etc. for > the purpose of better support under the OI/Solaris driver model but > these things can take a while to obtain, so if anybody knows of > existing open source versions I’ll jump on it. > > Thanks, > Deano A tool to help the end user know *when* they should run the reformatter tool would be helpful too. I know we can just wait until performance "degrades", but it would be nice to see what % of blocks are in use, etc. Ray ___ 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] Looking for 3.5" SSD for ZIL
Secure Erase is currently a entire drive function, its writes all the cell resetting it. It also updates the firmware GC maps so it knows the drive is clean. Trim just gives more info the firmware that a block is unused (as normally a delete is just updating an index table and the firmware has no way of knowing which cells are no longer needed by the OS). Currently firmware is meant to help conventional file system usage. However ZIL isn't normal usage and as such *IF* and it's a big if, we can effectively bypass the firmware trying to be clever or at least help it be clever then we can avoid the downgrade over time. In particular if we could secure erase a few cells as once as required, the lifetime would be much longer, I'd even argue that taking the wear leveling off the drives hand would be useful in the ZIL case. The other thing is the slow down only occurs once the SSD fills and has to start getting clever where to put things and which cells to change, for a ZIL that is again something we could avoid in software fairly easy. Its also worth putting this in perspective, a complete secure erase every night to restore performance to your ZIL would still let the SSD last for *years*. And given how cheap some SSD are, it is probably still cheaper to effectively burn the ZIL out and just replace it once a year. Maybe not a classic level of RAID but the very essence of the idea, lots of cheap can be better than expensive if you know what you are doing. Bye, Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Christopher George Sent: 23 December 2010 16:46 To: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] Looking for 3.5" SSD for ZIL > However, this *can* be overcome by frequently re-formatting the SSD (not > the Solaris format, a low-level format using a vendor-supplied utility). For those looking to "Secure Erase" a OCZ SandForce based SSD to reclaim performance, the following OCZ Forum thread might be of interest: http://www.ocztechnologyforum.com/forum/showthread.php?75773-Secure-Erase-TR IM-and-anything-else-Sandforce OCZ uses the term "DuraClass" as a catch-all for algorithms controlling wear leveling, drive longevity... There is a direct correlation between Secure Erase frequency and expected SSD lifetime. Thread #1 detailing a recommended frequency of Secure Erase use: "3) Secure erase a drive every 6 months to free up previously read only blocks, secure erase every 2 days to get round Duraclass and you will kill the drive very quickly" Thread #5 explaining DuraClass and relationship to TRIM: "Duraclass is limiting the speed of the drive NOT TRIM. TRIM is used along with wear levelling." Thread #6 provides more details of DuraClass and TRIM: "Now Duraclass monitors all writes and control's encryption and compression, this is what effects the speed of the blocks being written to..NOT the fact they have been TRIM'd or not TRIM'd." "You guys have become fixated at TRIM not speeding up the drive and forget that Duraclass controls all writes incurred by the drive once a GC map has been written." Above excerpts written by a OCZ employed thread moderator (Tony). Best regards, Christopher George Founder/CTO www.ddrdrive.com -- 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] A few questions
Edward Ned Harvey wrote > I don't know if anyone has real numbers, dollars contributed or number of > developer hours etc, but I think it's fair to say that oracle is probably > contributing more to the closed source ZFS right now, than the rest of the > world is contributing to the open source ZFS right now. Also, we know that > the closed source ZFS right now is more advanced than the open source ZFS > (zpool 31 vs 28). Oracle closed source ZFS is ahead, and probably > developing faster too, than the open source ZFS right now. > If anyone has any good way to draw more contributors into the open source > tree, that would also be useful and appreciated. Gosh, it would be nice to > get major players like Dell, HP, IBM, Apple contributing into that project. This is something that Illumos/Open source ZFS needs to decide what it wants, effectively we can't innovate ZFS without breaking capability... because our Illumos ZPool version 29 (if we innovate) will not be Oracle Zpool version 29. If we want open-source ZFS to we need to make that choice and let everyone know, apart from submitting bug fixes to zpool v28, are I'm not sure if other changed would be welcome? So honestly do we want to innovate ZFS (I do) or do we just want to follow Oracle? Bye, Deano de...@cloudpixies.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] A few questions
Edward Ned Harvey wrote > From: Deano [mailto:de...@rattie.demon.co.uk] > Sent: Wednesday, January 05, 2011 9:16 AM > > So honestly do we want to innovate ZFS (I do) or do we just want to follow > Oracle? > Well, you can't follow Oracle. Unless you wait till they release something, > reverse engineer it, and attempt to reimplement it. I am quite sure you'll > be sued if you do that. > > If you want forward development in the open source tree, you basically have > only one option: Some major contributor must have a financial interest, and > commit to a real concerted development effort, with their own roadmap, which > is intentionally designed NOT to overlap with the Oracle roadmap. > Otherwise, the code will stagnate. Why does it need a big backer? Erm ZFS isn't that large or amazingly complex code. It is *good* code but take 100s of developers and a fortune to develop? Erm nope (which I'd bet it never had at Sun either). Why not overlap Oracle? what has it got to do with Oracle if we have split into ZFS (Oracle) and "OpenZFS" in future. "OpenZFS" will get whatever features developers feel that want or they need to develop for it. This is the fundamental choice of Open source ZFS, illumos and OpenIndiania (and other distributions) have to decide, what is there purpose? Is it a free compatible (though trailing) version of Oracle Solaris OR a platform that shared an ancestor with Oracle Solaris via Sun OpenSolaris but now is its own evolutionary species, with no more connection than I have with a 15th cousin removed on my great, great, great, grandfathers side. This isn't even a theoretical what if situation for me, I have a major modification to ZFS (still being developed), it has no basis on Oracle or anybody elses needs just mine. It is what I felt I needed and ZFS was the right base for it. Now will that go into "OpenZFS"? Honestly I don't know yet, because not sure it would be wanted (it will be incompatible with Oracle ZFS) and personally, commercially I'm not sure if it's the right move to open source the feature. I bet I'm not the only small developer out there in a similar situation, the landscape is very unclear about what actually the community wants to do going forward, and whether we will have or even want "OpenZFS" and Oracle ZFS or Oracle ZFS and 90% compatibles (always trailing) or Oracle ZFS + DevA ZFS + DevB ZFS + DevC ZFS. Bye, Deano de...@cloudpixies.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zil and root on the same SSD disk
>From my notes from mirroring a new install (I install first then mirror). You won't need pfexec if your super-user. Inside format, fdisk twice first time delete anything there, second time it will ask you if you want to install a default Solaris2 setup. Obviously change the disk id to match your system. pfexec format fdisk (delete if required) and install standard Solaris2 pfexec prtvtoc /dev/rdsk/c1d0s2 | pfexec fmthard -s - /dev/rdsk/c2d0s2 pfexec zpool attach -f rpool c1d0s0 c2d0s0 I've never put a ZIL on the same disk, so can't help there sorry. HTH, Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Per Jorgensen Sent: 12 January 2011 20:51 To: zfs-discuss@opensolaris.org Subject: [zfs-discuss] zil and root on the same SSD disk Hi got a brand new server with 14 x 2TB disk, and 2X160GB SSD disk , my plan was to install opensolaris on one of the SSD disk and then zfs mirror the root disk onto the second SSD disk , but since the server will handle some sync NFS write i also want to add a zil log on the same SSD disks, also mirrored. I don't have in depth knowledge on solaris or opensolaris , and don't know much about how partitions works on solaris. I have tried the last 2 days solving this , and reading howtos on the net , but have not been able to find any step by step howto explaining how I should do it. :-( I have tried creating on big solaris2 partition , and then used 140G to the system , and then make a new slice the my zil , witch looked to work , at least i could add the 20G slice as log device to my pool , but then the problem came when i tried to to clone the partition map from the system SSD to the second SSD disk with this command prtvtoc /dev/rdsk/c7t0d0s2 | fmthard -s - /dev/rdsk/c7t1d0s2 it said something about overlapping partitions/slices ( unfortunately i did not save the output of the error ) but what is the right way to do this , should i create one big solaris2 partitions and then slice it up or should I create 2 separate partitions , and what is the right way to mirror both the system disk and zil log to the second SSD disk. And is i possible to do the partitioning from the installer ? ( I am installing opensolaris from the Live CD) please , hoping someone could provide me with a nice step by step howto on this , or maybe guide be through. br Per Jorgensen -- 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] mix 4k wdd drives whit 512 WD drives ?
If 512B drive is used with 4KiB ashift, there may be a performance lost (as
more data will be pushed and read from the drive).
It not so much the drives are lying, just they don't implement the ATAPI
standard (for SATA) to tell the OS they are really 4KiB drives. A firmware
update would fix this. The modern OpenSolaris children (S11E, OpenIndiana,
etc.) all read the physical size correctly when its provided via the drive.
Illumos will be providing support at the driver level via a driver look up
table quite soon for drives that don't tell the OS the physical block size
and I would expect other OS's will also hide the problem at the driver level
going forward.
For now zpool pool fixes are a reasonable work-around. The previous linked
zpool forces 4KiB which might not be ideal if you are also using non 4KiB
drives. A link to a zpool with a command line block-size is on the
OpenIndiana wiki at this link
http://wiki.openindiana.org/oi/SATA+-+Advanced+Format+and+4K+Sector+drives
HTH,
Deano
de...@cloudpixies.com
-Original Message-
From: zfs-discuss-boun...@opensolaris.org
[mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Tomas Ögren
Sent: 26 January 2011 17:01
To: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] mix 4k wdd drives whit 512 WD drives ?
On 26 January, 2011 - Benji sent me these 0,8K bytes:
> Those WD20EARS emulate 512 bytes sectors, so yes you can freely mix
> and match them with other "regular" 512 bytes drives. Some have
> reported slower read/write speeds but nothing catastrophic.
For some workloads, 3x slower than it should be.
> Or you can create a new 4K aligned pool (composed of only 4K drives!)
> to really take advantage of them. For that, you will need a modified
> zpool command to sets the ashift value of the pool to 12.
A 4k aligned pool will work perfectly on a 512b aligned disk, it's just
the other way that's bad. I guess ZFS could start defaulting to 4k, but
ideally it should do the right thing depending on content (although
that's hard for disks that are lying).
/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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Lower latency ZIL Option?: SSD behind Controller BB Write Cache
Hi Edward, Do you have a source for the 8KiB block size data? whilst we can't avoid the SSD controller in theory we can change the smallest size we present to the SSD to 8KiB fairly easily... I wonder if that would help the controller do a better job (especially with TRIM) I might have to do some test, so far the assumption (even inside sun's sd driver) is that SSD are really 4KiB even when the claim 512B, perhaps we should have an 8KiB option... Thanks, Deano de...@cloudpixies.com -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Edward Ned Harvey Sent: 28 January 2011 13:25 To: 'Eff Norwood'; zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] Lower latency ZIL Option?: SSD behind Controller BB Write Cache > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Eff Norwood > > We tried all combinations of OCZ SSDs including their PCI based SSDs and > they do NOT work as a ZIL. After a very short time performance degrades > horribly and for the OCZ drives they eventually fail completely. This was something interesting I found recently. Apparently for flash manufacturers, flash hard drives are like the pimple on the butt of the elephant. A vast majority of the flash production in the world goes into devices like smartphones, cameras, tablets, etc. Only a slim minority goes into hard drives. As a result, they optimize for these other devices, and one of the important side effects is that standard flash chips use an 8K page size. But hard drives use either 4K or 512B. The SSD controller secretly remaps blocks internally, and aggregates small writes into a single 8K write, so there's really no way for the OS to know if it's writing to a 4K block which happens to be shared with another 4K block in the 8K page. So it's unavoidable, and whenever it happens, the drive can't simply write. It must read modify write, which is obviously much slower. Also if you look up the specs of a SSD, both for IOPS and/or sustainable throughput... They lie. Well, technically they're not lying because technically it is *possible* to reach whatever they say. Optimize your usage patterns and only use blank drives which are new from box, or have been fully TRIM'd. Pt... But in my experience, reality is about 50% of whatever they say. Presently, the only way to deal with all this is via the TRIM command, which cannot eliminate the read/modify/write, but can reduce their occurrence. Make sure your OS supports TRIM. I'm not sure at what point ZFS added TRIM, or to what extent... Can't really measure the effectiveness myself. Long story short, in the real world, you can expect the DDRDrive to crush and shame the performance of any SSD you can find. It's mostly a question of PCIe slot versus SAS/SATA slot, and other characteristics you might care about, like external power, etc. ___ 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] ZFS and TRIM
Whilst the driver supports TRIM, ZFS doesn't yet. So in practice it's not supported. Bye, Deano de...@cloudpixies.com -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Brandon High Sent: 29 January 2011 18:40 To: Edward Ned Harvey Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] ZFS and TRIM On Sat, Jan 29, 2011 at 8:31 AM, Edward Ned Harvey wrote: > What is the status of ZFS support for TRIM? I believe it's been supported for a while now. http://www.c0t0d0s0.org/archives/6792-SATA-TRIM-support-in-Opensolaris.html -B -- Brandon High : bh...@freaks.com ___ 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] ZFS and TRIM
Even without TRIM and lots of use, SSD are still likely to help as ZIL and L2ARC cache units better than spindle disks, however don't expect the same performance you got after a fresh wipe/install. It makes sense to go with the brands with the best garbage collector you can and also if you can leave more space unused, that helps. Bye, Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Orvar Korvar Sent: 04 February 2011 13:20 To: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] ZFS and TRIM So, the bottom line is that Solaris 11 Express can not use TRIM and SSD? Is that the conclusion? So, it might not be a good idea to use a SSD? -- 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] ZFS/Drobo (Newbie) Question
In zfs terminology each of the groups you have is a VDEV and a zpool can be made of a number of VDEVs. This zpool can then be mounted as a single filesystem, or you can split it into as many filesystems as you wish. So the answer is yes to all the configurations you asked about and a lot more :) Bye, Deano de...@cloudpixies.com -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Gaikokujin Kyofusho Sent: 05 February 2011 17:55 To: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] ZFS/Drobo (Newbie) Question Thank you kebabber. I will try out indiana and virtual box to play around with it a bit. Just to make sure I understand your example, if I say had a 4x2tb drives, 2x750gb, 2x1.5tb drives etc then i could make 3 groups (perhaps 1 raidz1 + 1 mirrored + 1 mirrored), in terms of accessing them would they just be mounted like 3 partitions or could it all be accessed like one big partition? Anywho, I have indiana DL'ing now (very slow connection so thought I would post while i wait). Cheers, -Gaiko -- 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] SIL3114 and sparc solaris 10
That card works on OI-148 x86 if its SATA mode (tested it myself, RAID does not), which should also work on the SPARC version of the OS (common driver). Would mean upgrading to OpenIndiana and using the in development SPARC SKU but if you're adventurous and nothing else works... Bye, Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Mauricio Tavares Sent: 23 February 2011 13:18 To: zfs-discuss@opensolaris.org Subject: [zfs-discuss] SIL3114 and sparc solaris 10 Perhaps a bit off-topic (I asked on the rescue list -- http://web.archiveorange.com/archive/v/OaDWVGdLhxWVWIEabz4F -- and was told to try here), but I am kinda shooting in the dark: I have been finding online scattered and vague info stating that this card can be made to work with a sparc solaris 10 box (http://old.nabble.com/eSATA-or-firewire-in-Solaris-Sparc-system-td27150246. html is the only link I can offer right now). Can anyone confirm or deny that? ___ 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] best migration path from Solaris 10
Nexenta are a great company (I'm no way affiliated with them btw), if for no other reason being willing to invest in Illumos and by that OpenIndiana and NCP (for which they charge nothing). If you need a large enterprise commercially backed storage server system, NextentaStor is the answer. If you want a CLI OS, NCP or OpenIndiana text only will fulfill that spot (there is also illumos-extra which is even more stripped down to bare minimum), if a GUI or desktop is required OpenIndiana has that covered. Whilst there isn't yet official commercial support for OpenIndiana, that is something that has been brought up and the feeling is that it is something that would like to be offered at some point in time, it is just the logistics and organization of that support has to be setup. If it became a deal breaker I'd suggest talking to a senior person of OI, as it possible something could be arranged. I expect we are no more than 6 months away from Illumos being the defacto open source foundation for all the major distributions, which will then start freeing up a lot of developer resources to continue and improve things, beyond this initial get everything together period. ZFS open source future is being hammered out, with hopefully a cross platform working body to promote and move it forward appearing. I know everyone involved is both eager to make sure it's truly open and portable (with support for Illumos/OI, FreeBSD, Linux and OS-X in working or in-progress) and that it has a future regardless of any code drops from Oracle (they are of course welcome if they come, but clearly at this point it can't be relied upon). Personally I think OpenIndiana with Illumos foundations, is a great enterprise quality open source OS with a great future and a bunch of really committed guys and gals behind it. My 2P, Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Garrett D'Amore Sent: 18 March 2011 22:15 To: Paul B. Henson Cc: openindiana-disc...@openindiana.org; zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] best migration path from Solaris 10 Thanks for thinking about us, Paul. A few quick thoughts: a) Nexenta Core Platform is a bare-bones OS. No GUI, in other words (no X11.) It might well suit you. b) NCP 3 will not have an upgrade path to NCP 4. Its simply too much change in the underlying packaging. c) NCP 4 is still 5-6 months away. We're still developing it. d) NCP 4 will make much more use of the illumos userland, and only use Debian when illumos doesn't have an equivalent. e) NCP comes entirely unsupported. NexentaStor is a commercial product with real support behind it, though. f) *Today*, NexentaStor 3 has newer code in it than NCP. That will be changing, as we will be keeping the two much more closely in sync starting with 3.1. g) If you want to self support, OpenIndiana or NCP are both good options. NCP has debian packaging, and lacks a bunch of the GUI goodies. NCP 3 is not as new as OI, but is probably a bit more proven. Hopefully the additional information is helpful to you. - Garrett ___ 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] [OpenIndiana-discuss] best migration path from Solaris 10
Thats not quite right, Illumos is open source continuation of ONNV, which is the core foundation, however it doesn't include other consolidation that made up OpenSolaris. OpenIndiana does, it takes all those consolidations and produces a working OS you can install. Of course the biggest and most important of those consolidation is Illumos. The reason OI is only now slowly moving to Illumos, it has many other consolidations that also required work before a safe move could be made, and also keeping OpenIndiana in line with the closed source variants. There are other forks for both areas (ONNV replacements and installable OS distributions), if for some reason Illumos and OpenIndiana aren't suitable. HTH, Deano -Original Message- From: Pasi Kärkkäinen [mailto:pa...@iki.fi] Sent: 19 March 2011 14:58 To: Michael DeMan Cc: openindiana-disc...@openindiana.org; zfs-discuss@opensolaris.org Subject: Re: [OpenIndiana-discuss] [zfs-discuss] best migration path from Solaris 10 On Fri, Mar 18, 2011 at 06:26:37PM -0700, Michael DeMan wrote: > ZFSv28 is in HEAD now and will be out in 8.3. > > ZFS + HAST in 9.x means being able to cluster off different hardware. > > In regards to OpenSolaris and Indiana - can somebody clarify the relationship there? It was clear with OpenSolaris that the latest/greatest ZFS would always be available since it was a guinea-pig product for cost conscious folks and served as an excellent area for Sun to get marketplace feedback and bug fixes done before rolling updates into full Solaris. > > To me it seems that Open Indiana is basically a green branch off of a dead tree - if I am wrong, please enlighten me. > Illumos project was started as a fork of OpenSolaris when Oracle was still publishing OpenSolaris sources. Then Oracle closed OpenSolaris development, and decided to call upcoming (closed) versions "Solaris 11 Express", with no source included. Illumos project continued the development based on the latest published OpenSolaris sources, and a bit later OpenIndiana *distribution* was announced to deliver a binary distro based on OpenSolaris/Illumos. So in short Illumos is the development project, which hosts the new sources, and OpenIndiana is a binary distro based on it. -- Pasi > On Mar 18, 2011, at 6:16 PM, Roy Sigurd Karlsbakk wrote: > > >> I think we all feel the same pain with Oracle's purchase of Sun. > >> > >> FreeBSD that has commercial support for ZFS maybe? > > > > Fbsd currently has a very old zpool version, not suitable for running with SLOGs, since if you lose it, you may lose the pool, which isn't very amusing... > > > > Vennlige hilsener / 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 ___ OpenIndiana-discuss mailing list openindiana-disc...@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] best migration path from Solaris 10
OpenIndiana and others (i.e. Benunix) are distributions that actively support full desktop workstations based on the Illumos base. It is true, that the storage server application is a popular one and so has supporters both commercially and others. ZFS is amazing and quite rightly it stands out, it works even better when used with zones, crossbow, dtrace, etc. and so its obvious to see what it's a focus and often seems the only priority. However is isn't the only interest, by a long shot. The SFE package repositories has many packages available to install for when the binary packaging aren't up to date. OpenIndiana is hard at work trying to build bigger binary repositories with more apps and newer versions. A simple "pkg install APPLICATION" is the aim for the majority of main applications. Is it not moving fast enough, or missing the packages you need? Well that's the beauty of Open Source, we welcome and have systems to help newcomers add and update the packages and applications they want, so we all benefit. Ultimately I'd (and I'm sure many would) like to have a level of binary repositories similar to Debian, with stable and faster changing place repos and support for many different applications, however that requires a lot of work and manpower. Bye, Deano -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Fajar A. Nugraha Sent: 23 March 2011 01:09 To: Jeff Bacon Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] best migration path from Solaris 10 On Wed, Mar 23, 2011 at 7:33 AM, Jeff Bacon wrote: >> I've also started conversations with Pogo about offering an > OpenIndiana >> based workstation, which might be another option if you prefer more of > Sometimes I'm left wondering if anyone uses the non-Oracle versions for > anything but file storage... ? Seeing that userland programs for *Solaris and derivatives (GUI, daemons, tools, etc) is usually late compared to bleeding-edge Linux distros (e.g. Ubuntu), with no particular dedicated team working on improvement there, I'm guessing the answer will be "highly unlikely". -- Fajar ___ 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] [illumos-Developer] ZFS working group and feature flags proposal
Hi Matt, That's looks really good, I've been meaning to implement a ZFS compressor (using a two pass, LZ4 + Arithmetic Entropy), so nice to see a route with which this can be done. One question, is the extendibility of RAID and other similar systems, my quick perusal makes me thinks this is handled by simple asserting a new feature using the extension mechanism, but perhaps I've missed something? Do you see it being able to handle this situation? Its of course a slightly tricky one, as not only does it change data but potentially data layout as well... Great work ZFS working group :) Nice to see ZFS's future coming together! Bye, Deano ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
