My google-fu is coming up short on this one... I didn''t see that it had been discussed in a while ... What is the status of ZFS support for TRIM? For the pool in general... and... Specifically for the slog and/or cache??? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110129/56283ce0/attachment.html>
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Edward Ned Harvey > > My google-fu is coming up short on this one...? I didn''t see that it hadbeen> discussed in a while ...BTW, there were a bunch of places where people said "ZFS doesn''t need trim." Which I hope, by now, has been commonly acknowledged as bunk. The only situation where you don''t need TRIM on a SSD is when (a) you''re going to fill it once and never write to it again, which is highly unlikely considering the fact that you''re buying a device for its fast write performance... (b) you don''t care about performance, which is highly unlikely considering the fact that you bought a performance device ... (c) you are using whole disk encryption. This is a valid point. You would probably never TRIM anything from a fully encrypted disk ... In places where people said TRIM was thought to be unnecessary, the justification they stated was that TRIM will only benefit people whose usage patterns are sporadic, rather than sustained. The downfall of that argument is the assumption that the device can''t perform TRIM operations simultaneously while performing other operations. That may be true in some cases, or even globally, but without backing, it''s just an assumption. One which I find highly quesitonable.
Edward Ned Harvey wrote:>> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- >> bounces at opensolaris.org] On Behalf Of Edward Ned Harvey >> >> My google-fu is coming up short on this one... I didn''t see that it had >> > been > >> discussed in a while ... >> > > BTW, there were a bunch of places where people said "ZFS doesn''t need trim." > Which I hope, by now, has been commonly acknowledged as bunk. > > The only situation where you don''t need TRIM on a SSD is when (a) you''re > going to fill it once and never write to it again, which is highly unlikely > considering the fact that you''re buying a device for its fast write > performance... (b) you don''t care about performance, which is highly > unlikely considering the fact that you bought a performance device ... (c) > you are using whole disk encryption. This is a valid point. You would > probably never TRIM anything from a fully encrypted disk ... > > In places where people said TRIM was thought to be unnecessary, the > justification they stated was that TRIM will only benefit people whose usage > patterns are sporadic, rather than sustained. The downfall of that argument > is the assumption that the device can''t perform TRIM operations > simultaneously while performing other operations. That may be true in some > cases, or even globally, but without backing, it''s just an assumption. One > which I find highly quesitonable.TRIM could also be useful where ZFS uses a storage LUN which is sparsely provisioned, in order to deallocate blocks in the LUN which have previously been allocated, but whose contents have since been invalidated. In this case, both ZFS and whatever is providing the storage LUN would need to support TRIM. Out of interest, what other filesystems out there today can generate TRIM commands? -- Andrew Gabriel
On Sat, Jan 29, 2011 at 8:31 AM, Edward Ned Harvey <opensolarisisdeadlongliveopensolaris at nedharvey.com> 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 : bhigh at freaks.com
Whilst the driver supports TRIM, ZFS doesn''t yet. So in practice it''s not supported. Bye, Deano deano at cloudpixies.com -----Original Message----- From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Brandon High Sent: 29 January 2011 18:40 To: Edward Ned Harvey Cc: zfs-discuss at opensolaris.org Subject: Re: [zfs-discuss] ZFS and TRIM On Sat, Jan 29, 2011 at 8:31 AM, Edward Ned Harvey <opensolarisisdeadlongliveopensolaris at nedharvey.com> 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 : bhigh at freaks.com _______________________________________________ zfs-discuss mailing list zfs-discuss at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Brandon High <bhigh at freaks.com> wrote:> On Sat, Jan 29, 2011 at 8:31 AM, Edward Ned Harvey > <opensolarisisdeadlongliveopensolaris at nedharvey.com> 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.htmlThe command is implemented in the sata driver but there does ot seem to be any user of the code. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Mon, Jan 31, 2011 at 03:41:52PM +0100, Joerg Schilling wrote:> Brandon High <bhigh at freaks.com> wrote: > > > On Sat, Jan 29, 2011 at 8:31 AM, Edward Ned Harvey > > <opensolarisisdeadlongliveopensolaris at nedharvey.com> 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 > > The command is implemented in the sata driver but there does ot seem to be any > user of the code. >Btw is the SCSI equivalent also implemented? iirc it was called SCSI UNMAP (for SAS). -- Pasi
Pasi K?rkk?inen <pasik at iki.fi> wrote:> On Mon, Jan 31, 2011 at 03:41:52PM +0100, Joerg Schilling wrote: > > Brandon High <bhigh at freaks.com> wrote: > > > > > On Sat, Jan 29, 2011 at 8:31 AM, Edward Ned Harvey > > > <opensolarisisdeadlongliveopensolaris at nedharvey.com> 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 > > > > The command is implemented in the sata driver but there does ot seem to be any > > user of the code. > > > > Btw is the SCSI equivalent also implemented? iirc it was called SCSI UNMAP (for SAS).The high level interface is called unmap .... it seems that the planned interface for ZFS is to send a raw SPC3_CMD_UNMAP SCSI command to the driver and that this command is translated into TRIM in the sata case. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ,
On 01/31/11 01:09 PM, Pasi K?rkk?inen wrote:> On Mon, Jan 31, 2011 at 03:41:52PM +0100, Joerg Schilling wrote: > >> Brandon High<bhigh at freaks.com> wrote: >> >> >>> On Sat, Jan 29, 2011 at 8:31 AM, Edward Ned Harvey >>> <opensolarisisdeadlongliveopensolaris at nedharvey.com> 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 >>> >> The command is implemented in the sata driver but there does ot seem to be any >> user of the code. >> >> > Btw is the SCSI equivalent also implemented? iirc it was called SCSI UNMAP (for SAS). >No. - Garrett> -- Pasi > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
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
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-bounces at opensolaris.org [mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Orvar Korvar Sent: 04 February 2011 13:20 To: zfs-discuss at 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 at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Sat, Jan 29, 2011 at 11:31:59AM -0500, Edward Ned Harvey wrote:> What is the status of ZFS support for TRIM?[...] I''ve no idea, but because I wanted to add such support for FreeBSD/ZFS for a while now, I''ll share my thoughts. The problem is where to put those operations. ZFS internally have ZIO_TYPE_FREE request, which represents exactly what we need - offset and size to free. It would be best to just pass those requests directly to VDEVs, but we can''t do that. There might be transaction group that will never be committed, because of a power failure and we TRIMed blocks that we want to use after boot. Ok, maybe we could just make such operation part of the transaction group? No, we can''t do that too. If we start committing transactions and we execute TRIM operations we may still have power failure and TRIM operations on old blocks cannot be undone, so we will get back to invalid data. So why not to move TRIM operations to the next transaction group? That''s doable, although we still need to be careful not to TRIM blocks that were freed in the previous transaction group, but are reallocated in the current one (or if we TRIM, we TRIM first and then write). Unfortunately we don''t want to TRIM blocks immediately. Take into account disks that are lying about cache flush operation and because of that ZFS tries to keep freed blocks from the few last transaction groups around, so you can forcibly rewind to one of the previous txgs if such corruption occur. My initial idea was to implement 100% reliable TRIM, so that I can implement secure delete using it, eg. if ZFS is placed on top of disk encryption layer, I can implement TRIM in this layer as ''overwrite the given range with random data''. Making TRIM 100% reliable will be very hard, IMHO. But in most cases we don''t need TRIM to be so perfect. My current idea is to delay TRIM operation for some number of transaction groups. For example if block is freed in txg=5, I''ll send TRIM for it after txg=15 (if it wasn''t reassigned in the meantime). This is ok if we crash before we get to txg=15, because the only side-effect is that next write to this range might be a little slower. -- Pawel Jakub Dawidek http://www.wheelsystems.com pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110204/f5b06ead/attachment.bin>
> So, the bottom line is that Solaris 11 Express can not use > TRIM and SSD?Correct.> So, it might not be a good idea to use a SSD?It is true that a Flash based SSD, will be adversely impacted by ZFS not supporting TRIM, especially for the ZIL accelerator. But a DRAM based SSD is immune to TRIM support status and thus unaffected. Actually, TRIM support would only add unnecessary overhead to the DDRdrive X1''s device driver. Best regards, Christopher George Founder/CTO www.ddrdrive.com -- This message posted from opensolaris.org
On Fri, February 4, 2011 09:30, Pawel Jakub Dawidek wrote:> But in most cases we don''t need TRIM to be so perfect. My > current idea is to delay TRIM operation for some number of transaction > groups. For example if block is freed in txg=5, I''ll send TRIM for it > after txg=15 (if it wasn''t reassigned in the meantime). This is ok if > we crash before we get to txg=15, because the only side-effect is that > next write to this range might be a little slower.Off the top of my head, I can then of two instances where non-recent blocks would be needed: * snapshots * importing via recovery mode ("zpool import -F mypool") For the latter, given that each vdev label can have up to 128 uberblocks, recovery mode import can go back at least 128 transactions for a single non-mirrored device, so you''d potentially need to not TRIM at least 128 transactions back for the worst case. Of course if you have a pair of mirrored vdevs/disks, and each one has 128 uberblocks, that''s potentially 256 txgs that you can recover from (and it goes up the more vdevs you have of course). That may be excessive, but perhaps there could be a tunable sysctl on a max amount to go back TRIMing (defaulting to 128? 64? 32?). I''m not sure how ZFS keeps track of snapshots: is there something in-memory, or is it necessary to walk the tree? Perhaps getting a list of snapshots, getting the oldest birth time (i.e., smallest txg), and TRIMing and blocks that have one less than that number? Given that txgs are committed every 5-30s, and I/O isn''t done between them, that "idle" time could be utilized for sending TRIM commands? Presumably the Oracle folks are looking at this as well internally.
On 2/4/2011 7:39 AM, Christopher George wrote:>> So, the bottom line is that Solaris 11 Express can not use >> TRIM and SSD? > Correct. > >> So, it might not be a good idea to use a SSD? > It is true that a Flash based SSD, will be adversely impacted by > ZFS not supporting TRIM, especially for the ZIL accelerator. > > But a DRAM based SSD is immune to TRIM support status and > thus unaffected. Actually, TRIM support would only add > unnecessary overhead to the DDRdrive X1''s device driver. > > Best regards, > > Christopher George > Founder/CTO > www.ddrdrive.comBottom line here is this: for a ZIL, you have a hierarchy of performance, each about two orders of magnitude faster than the prior: 1. hard drive 2. NAND-based SSD 3. DRAM-based SSD You''ll still get a very noticeable improvement of using a NAND (flash) SSD over not using a dedicated ZIL device. It just won''t be the improvement "promised" by the SSD packaging. If that performance isn''t sufficient for you, then a DRAM SSD is your best bet. Note that even if TRIM would be supported, it wouldn''t remove the whole penalty that a fully-written-to NAND SSD suffers. NAND requires that any block which was priorly written to be erased BEFORE you can write to it again. TRIM only helps with using unwritten blocks inside pages, and to schedule whole page erasures inside the SSD controller. I can''t put real numbers on it, but I would suspect that rather than suffer a 10x loss of performance, you might only lose 5x or so if TRIM were properly usable. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
Ok, I read a bit more on TRIM. It seems that without TRIM, there will be more unnecessary reads and writes on the SSD, the result being that writes can take long time. A) So, how big of a problem is it? Sun has for long sold SSDs (for L2ARC and ZIL), and they dont use TRIM? So, is TRIM not a big concern says Sun? B) And you talk about DRAM based SSDs, that are immune to TRIM and such problems. How much do they cost, where can I find them? C) I have been waiting for Intels next gen SSD3, the G3, which will be released 11 march. But Solaris does not support TRIM. Or, ZFS supports TRIM, but the OS does not use it. When can we expect TRIM support in Solaris? Shortly, or it is not planned? The next release? Does it require a major rewrite of Solaris? Is it much work? D) Will OpenIndiana and Illumos tackle the TRIM problem? -- This message posted from opensolaris.org
Orvar Korvar <knatte_fnatte_tjatte at yahoo.com> wrote:> Ok, I read a bit more on TRIM. It seems that without TRIM, there will be more unnecessary reads and writes on the SSD, the result being that writes can take long time. > > A) So, how big of a problem is it? Sun has for long sold SSDs (for L2ARC and ZIL), and they dont use TRIM? So, is TRIM not a big concern says Sun? > > B) And you talk about DRAM based SSDs, that are immune to TRIM and such problems. How much do they cost, where can I find them?There is only a need for TRIM, when you are on a background storage that needs extra time in order to prepare an attempt to overwrite parts. There is no such for RAM, but there is a related need with insulated gate technology based storage.> C) I have been waiting for Intels next gen SSD3, the G3, which will be released 11 march. But Solaris does not support TRIM. Or, ZFS supports TRIM, but the OS does not use it. When can we expect TRIM support in Solaris? Shortly, or it is not planned? The next release? Does it require a major rewrite of Solaris? Is it much work?The SATA driver seems to support TRIM issued as a SCSI UNMAP command. ZFS does not support TRIM.> D) Will OpenIndiana and Illumos tackle the TRIM problem?OpenIndiana is a distro and it depends on a ONNV project. From my current information, OpenIndiana today is based on build 147+ from the last Snorcle mercurial. I cannot speak for Illumos as I did not see and announcements from a related hacker so far. For Schillix-ON (the ONNV base used by future Schillix distros), I can say that the highest priority is assigned to tasks that emancipate OpenSolaris and remove left-over closed bits. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
So... Sun''s SSD used for ZIL and L2ARC does not use TRIM, so how big a problem is lack of TRIM in ZFS really? It should not hinder anyone to run without TRIM? I didnt really understand the answer on this question. Because Sun''s SSD does not use TRIM - and it is not consider a hinder? A home user could use SSD without greater problems? If I format the disk every year and reinstall, would that help? I am concerned as a home user... Regarding the DDRAM SSDs that dont need TRIM, they seem interesting. I got a mail from CTO of DDrive who did not want to mail publicly to this list (advertisment he said) but it seems expensive, the DDdrive X1 which is targeted to Enterprise costs $2000 USD. Are there any home user variants? But reading this presentation, it seems to have a point of using DDRAM variants: http://www.ddrdrive.com/zil_accelerator.pdf Quite interesting info -- This message posted from opensolaris.org
On 2/5/2011 5:44 AM, Orvar Korvar wrote:> So... Sun''s SSD used for ZIL and L2ARC does not use TRIM, so how big a problem is lack of TRIM in ZFS really? It should not hinder anyone to run without TRIM? I didnt really understand the answer on this question. Because Sun''s SSD does not use TRIM - and it is not consider a hinder? A home user could use SSD without greater problems? If I format the disk every year and reinstall, would that help? I am concerned as a home user...As a home user, you don''t really care about support for TRIM. Even a reasonable SSD (i.e. not "Enterprise" level) will provide a very significant boost when used as a ZIL, over just having bare drives (in particular, if you just have SATA 7200 or 5400 RPM drives, you will really notice the boost). Ideally, you want an SSD with a battery or supercapacitor, but they''re pretty expensive right now. (i.e. OCZ''s Vertex 2 Pro series). If you have a dependable UPS for the system, and can accept the (small) risk that you might lose the last write commit on certain power-loss scenarios, a mid-line SSD is entirely OK. Note that a ZIL cache device is NOT A WRITE CACHE. ZIL is there for synchronous writes only, so that ZFS can essentially turn synchronous writes into asynchronous writes. NFS is a big sync() write user, but Samba is not. You won''t notice any improvement over Samba when using a ZIL cache. Don''t bother with a reformat of the SSD. It won''t help, other than maybe a yearly reformat would be good to reset absolutely everything inside it, but, you won''t notice any really difference even after you do.> Regarding the DDRAM SSDs that dont need TRIM, they seem interesting. I got a mail from CTO of DDrive who did not want to mail publicly to this list (advertisment he said) but it seems expensive, the DDdrive X1 which is targeted to Enterprise costs $2000 USD. Are there any home user variants? But reading this presentation, it seems to have a point of using DDRAM variants: > http://www.ddrdrive.com/zil_accelerator.pdf > Quite interesting infoThere are a couple of things similar to the DDRdrive, but they''re all Enterprise-class, and going to cost you. There''s no $200 solution. Which is kind of sad, since building a DDRdrive-like thing reallly just requires 2 4Gbit DRAM chips, 2 4GBit NAND chips, a small battery, and a FPGA that does some basic PCI-E to Memory mapping (and, a little bit of extra DRAM->NAND copying if power is lost). Really, it''s entirely doable for someone with decent VLSI experience. The DDRdrive folks have got the experience to do it, but, honestly, its not a complex product. Bottom line, it''s maybe $50 in parts, plus a $100k VLSI Engineer to do the design. <wink> -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Orvar Korvar > > 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?Even without TRIM, SSD''s are still much faster than hard drives. They would be even faster if they had TRIM. But not as fast as DDRDrive. ;-)
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Erik Trimble > > Bottom line, it''s maybe $50 in parts, plus a $100k VLSI Engineer to do > the design. <wink>Well, only if there''s a high volume. If you''re only going to sell 10,000 of these devices, you won''t be able to mfgr it for $50. On a similar note, here are some funny current market prices: $9 external usb hard drive enclosure $29 external usb hard drive and enclosure $38 cheapest hard drive available without an enclosure also... $9 for 1Gbit ethernet $9 for 6Gbit sata card $500 for 10Gbit ethernet There''s clearly no argument possible saying the better hardware is the reason any one of those products costs more. The driving factor is mass production and volume pricing. Simply the most popular items are the cheapest. If the quality of hardware was the reason for the pricing being too high... I would happily settle for the 2G or 4G or 6G ethernet adapter for $20 or $60... But nobody bothers to invent an ethernet adapter between 1G and 10G because they would cost just as much as the 10G. Simply there is insufficient consumer demand to get the volume necessary for costs to come down...
Ok, so can we say that the conclusion for a home user is: 1) Using SSD without TRIM is acceptable. The only drawback is that without TRIM, the SSD will write much more, which effects life time. Because when the SSD has written enough, it will break. I dont have high demands for my OS disk, so battery backup is overkill for my needs. So I can happily settle for the next gen Intel G3 SSD disk, without worrying the SSD will break because Solaris has no TRIM support yet? 2) And later, when Solaris gets TRIM support, should I reformat or is there no need to reformat? I mean, maybe I must format and reinstall to get TRIM all over the disk. Or will TRIM immediately start to do it''s magic? -- This message posted from opensolaris.org
> 2) And later, when Solaris gets TRIM support, should I reformat or is > there no need to reformat? I mean, maybe I must format and reinstall > to get TRIM all over the disk. Or will TRIM immediately start to do > it''s magic?Trim works on the device level, so a reformat won''t be necessary Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 roy at 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.
On 2/6/2011 3:51 AM, Orvar Korvar wrote:> Ok, so can we say that the conclusion for a home user is: > > 1) Using SSD without TRIM is acceptable. The only drawback is that without TRIM, the SSD will write much more, which effects life time. Because when the SSD has written enough, it will break. > > I dont have high demands for my OS disk, so battery backup is overkill for my needs. > > So I can happily settle for the next gen Intel G3 SSD disk, without worrying the SSD will break because Solaris has no TRIM support yet?Yes. All modern SSDs will wear out, but, even without TRIM support, it will be a significant time (5+ years) before they do. Internal wear-leveling by the SSD controller results in an expected lifespan about the same as hard drives. TRIM really only impacts performance. For the ZFS ZIL use case, TRIM has only a small impact on performance - SSD performance for ZIL drops off quickly from peak, and supporting TRIM would only slightly mitigate this. For home use, lack of TRIM support won''t noticeably change your performance as a ZIL cache or lower the lifespan of the SSD. The Intel X25-M (either G3 or G2) would be sufficient for your purposes. In general, we do strongly recommend you put a UPS on your system, to avoid cache corruption in case of power outages.> > 2) And later, when Solaris gets TRIM support, should I reformat or is there no need to reformat? I mean, maybe I must format and reinstall to get TRIM all over the disk. Or will TRIM immediately start to do it''s magic?If/when TRIM is supported by ZFS, I would expect this to transparent to you, the end-user. You''d have to upgrade the OS to the proper new patchlevel, and *possibly* run a ''zpool upgrade'' to update the various pools to the latest version, but I suspect the latter will be completely unnecessary. TRIM support would come in ZFS''s guts, not in the pool format. Worst case is that you''d have to enable TRIM at the device layer, which would probably entail either editing a config file and rebooting, or just running some command to enable the feature. I can''t imagine it would require any reformating or reinstalling. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
On 2/6/2011 3:51 AM, Orvar Korvar wrote:> Ok, so can we say that the conclusion for a home user is: > > 1) Using SSD without TRIM is acceptable. The only drawback is that without TRIM, the SSD will write much more, which effects life time. Because when the SSD has written enough, it will break. > > I dont have high demands for my OS disk, so battery backup is overkill for my needs. > > So I can happily settle for the next gen Intel G3 SSD disk, without worrying the SSD will break because Solaris has no TRIM support yet?Yes. All modern SSDs will wear out, but, even without TRIM support, it will be a significant time (5+ years) before they do. Internal wear-leveling by the SSD controller results in an expected lifespan about the same as hard drives. TRIM really only impacts performance. For the ZFS ZIL use case, TRIM has only a small impact on performance - SSD performance for ZIL drops off quickly from peak, and supporting TRIM would only slightly mitigate this. For home use, lack of TRIM support won''t noticeably change your performance as a ZIL cache or lower the lifespan of the SSD. The Intel X25-M (either G3 or G2) would be sufficient for your purposes. In general, we do strongly recommend you put a UPS on your system, to avoid cache corruption in case of power outages.> > 2) And later, when Solaris gets TRIM support, should I reformat or is there no need to reformat? I mean, maybe I must format and reinstall to get TRIM all over the disk. Or will TRIM immediately start to do it''s magic?If/when TRIM is supported by ZFS, I would expect this to transparent to you, the end-user. You''d have to upgrade the OS to the proper new patchlevel, and *possibly* run a ''zpool upgrade'' to update the various pools to the latest version, but I suspect the latter will be completely unnecessary. TRIM support would come in ZFS''s guts, not in the pool format. Worst case is that you''d have to enable TRIM at the device layer, which would probably entail either editing a config file and rebooting, or just running some command to enable the feature. I can''t imagine it would require any reformating or reinstalling. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
On Sun, 6 Feb 2011, Orvar Korvar wrote:> > 1) Using SSD without TRIM is acceptable. The only drawback is that without TRIM, the SSD will write much more, which effects life time. Because when the SSD has written enough, it will break.Why do you think that the SSD should necessarily write much more? I don''t follow that conclusion. If I can figure out how to design a SSD which does not necessarily write much more, I suspect that an actual SSD designer can do the same. USB sticks and Compact Flash cards need not apply. :-) Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
On Mon, Feb 7 at 20:43, Bob Friesenhahn wrote:>On Sun, 6 Feb 2011, Orvar Korvar wrote: >> >>1) Using SSD without TRIM is acceptable. The only drawback is that without TRIM, the SSD will write much more, which effects life time. Because when the SSD has written enough, it will break. > >Why do you think that the SSD should necessarily write much more? I >don''t follow that conclusion. > >If I can figure out how to design a SSD which does not necessarily >write much more, I suspect that an actual SSD designer can do the >same.Blocks/sectors marked as being TRIM''d do not need to be maintained by the garbage collection engine. Depending on the design of the SSD, this can significantly reduce the write amplification of the SSD. -- Eric D. Mudama edmudama at bounceswoosh.org
On Fri, Feb 04, 2011 at 03:30:45PM +0100, Pawel Jakub Dawidek wrote:> On Sat, Jan 29, 2011 at 11:31:59AM -0500, Edward Ned Harvey wrote: > > What is the status of ZFS support for TRIM? > [...] > My initial idea was to implement 100% reliable TRIM, so that I can > implement secure delete using it, eg. if ZFS is placed on top of diskHmmm - IIRC, zfs loadbalances ZIL ops over available devs. Furthermore I guess, almost everyone, who considers SSDs for ZIL will use at least 2 devs (i.e. since there is "no big" benefit in having a mirror dev, many people will proably use one SSD/dev, some more "paranoid" people will choose to have a N-way mirror/dev). So why not turn the 2nd dev "temp. off" (freeze), do what you want (trim/reformat/etc) and than turn it on again? I assume of course, that the "loadbalancer" recognizes, when a dev goes "offline/online" and automatically uses the available ones, only ... If one doesn''t have at least 2 devs, don''t care about this home optimized setup ;-) Regards, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768