Re: Intel Updates SSDs, Supports TRIM, Faster Writes

[Kasper Sandberg <postmaster@metanurb.dk>]

On Tue, 2009-11-10 at 09:18 -0700, Chris Worley wrote:
> On Tue, Nov 10, 2009 at 9:01 AM, Majed B. <majedb@gmail.com> wrote:
> > Which disks can provide 2ms response with a read of 250 MB/s and write
> > of 170 MB/s other than SSDs?!
> 
> The drives I use average <50usecs latency at 4KB packets (properly
> measured as the complete turn-around time of a single outstanding
> I/O), 800MB/s reads and >600MB/s writes at 128KB blocks.
> 
> >
> > Are you saying that it doesn't matter whether we use Linux or Windows
> > with SSDs because the limitation is coming from the disk's controller
> > itself?
> 
> To some degree, yes, when using SSD's behind a controller, the
> controller is the biggest performance issue, and given they use
> chicklets for processors, they all hamper performance given the speed
> potential of the underlying storage.
> 
> As none of the enterprise distros are handling TRIM yet, W7 can claim
> it was first, and putting together a TRIM-capable kernel is manual
Except it wasnt, it may be earlier than the enterprise distros, but
thats not first.
> currently in Linux, and given only ext4 supports it (strangely, FAT
> supported it, then the code was pulled... XFS may support it, but I
> believe that's still in the works), you have the additional problem
> that ext4 has some maturity issues.  Porting "discard" to ext2/3 would
> not be too difficult, especially w/o journal considerations.
And given W7 supports it, it is going to have the same issues which
linux faces, i dont know what solution microsoft has chosen, but that
doesnt mean linux shouldnt choose the best one..

> 
> Chris
> >
> > On Tue, Nov 10, 2009 at 6:58 PM, Chris Worley <worleys@gmail.com> wrote:
> >> On Tue, Nov 10, 2009 at 8:43 AM, Majed B. <majedb@gmail.com> wrote:
> >>> Does that mean we won't be able to squeeze the juice out of Intel's
> >>> Extreme SSDs on Linux?
> >>
> >> The limitation is in the design.  You'll be able to get as much
> >> performance as they can offer, given the bad design (of putting SSS
> >> behind legacy controllers).
> >>
> >>>
> >>> What about those of us who use OpenFiler and build their own storage
> >>> solutions? We won't be able to provide solutions based on these SSDs
> >>> because the kernel support is crap?
> >>
> >> It's sub-optimal, written to make the best of a bad design, limiting
> >> performance of good designs, but not crap.
> >>
> >>>
> >>> I may have clients wanting to mix between SAS/SATA & SSD to load their
> >>> main database on the SSDs, but now it seems pointless since the
> >>> performance isn't gonna be that great :/
> >>
> >> You can still get much greater performance from SSS designed
> >> correctly.  Just don't do SSD's.
> >>
> >> Chris
> >>>
> >>> On Tue, Nov 10, 2009 at 6:39 PM, Chris Worley <worleys@gmail.com> wrote:
> >>>> On Tue, Nov 10, 2009 at 2:42 AM, Kasper Sandberg <postmaster@metanurb.dk> wrote:
> >>>>> On Mon, 2009-11-09 at 09:59 -0700, Chris Worley wrote:
> >>>>>> On Mon, Nov 9, 2009 at 9:42 AM, Majed B. <majedb@gmail.com> wrote:
> >>>>>> > Well, SATA uses SCSI emulation so I guess that's no problem, right?
> >>>>>>
> >>>>>> The only problem is SSD's put Solid State Storage (SSS) behind
> >>>>>> SATA/SAS controllers... while compatible w/ old disk technology, it
> >>>>>> severely limits performance (i.e. none of these SSD drives do even
> >>>>>> 300MB/s... while SSS drives do 800MB/s).  While the initial 2.6.27
> >>>>> No, around 280MB/s... and obviously they dont do more, because of the
> >>>>> simple limitation of the sata controllers.. this also means they dont
> >>>>> need to do as many channels as other devices..
> >>>>
> >>>> I'm not sure if you're agreeing or disagreeing here...
> >>>> 280MB/s<300MB/s, due to the "compatibility" based design of SSD's,
> >>>> while SSS, w/o a legacy controller, can do 800MB/s out of a single
> >>>> drive.
> >>>>
> >>>>>> drivers and ext4 "discard" worked very well with forward-thinking SSS
> >>>>>> not encumbered by old controller technology... but, SSD's were not
> >>>>>> able to handle it well:
> >>>>>>
> >>>>>> http://lwn.net/Articles/347511/
> >>>>>>
> >>>>>> So it looks like "design by committee" Linux is well behind Windows 7,
> >>>>> And how exactly does windows 7 handle this so much better?
> >>>>
> >>>> TRIM is in W7; NTFS support.  No Linux distro does.  And by the time
> >>>> "design by committee" gets through with it,we shouldn't have bothered.
> >>>>
> >>>>>> while Linux contemplates slowing new technology down to optimize for
> >>>>>> ill-designed SSD's.
> >>>>> It does?
> >>>>
> >>>> Those that speak loudest in the kernel development (and contribute the
> >>>> most) work for companies like Intel that promote the slower,
> >>>> controller-based, SSD's.
> >>>>
> >>>> Chris
> >>>>>>
> >>>>>> Be glad "thumb drives" didn't try to be floppy-drive-compatible!!!
> >>>>>>
> >>>>>> Chris
> >>>>>> >
> >>>>>> > On Mon, Nov 9, 2009 at 7:37 PM, Chris Worley <worleys@gmail.com> wrote:
> >>>>>> >> On Sun, Nov 8, 2009 at 6:13 PM, Majed B. <majedb@gmail.com> wrote:
> >>>>>> >>> The firmware which introduced the TRIM command was deemed buggy and
> >>>>>> >>> has been pulled out.
> >>>>>> >>>
> >>>>>> >>> Are there any filesystems that are TRIM-aware?
> >>>>>> >>
> >>>>>> >> Ext4 (at that level in the kernel, it's referred to as "discard", it's
> >>>>>> >> not TRIM until it's issued as a SCSI command).
> >>>>>> >>
> >>>>>> >> Chris
> >>>>>> >>>
> >>>>>> >>> On Sun, Nov 8, 2009 at 8:57 PM, Bill Davidsen <davidsen@tmr.com> wrote:
> >>>>>> >>>> For those of us playing with use of SSD for journals on ext[34], this does
> >>>>>> >>>> have implications for RAID performance.
> >>>>>> >>>>
> >>>>>> >>>> http://hardware.slashdot.org/story/09/10/27/1427209/Intel-Updates-SSDs-Supports-TRIM-Faster-Writes
> >>>>>> >>>>
> >>>>>> >>>> --
> >>>>>> >>>> Bill Davidsen <davidsen@tmr.com>
> >>>>>> >>>>  Unintended results are the well-earned reward for incompetence.
> >>>>>> >>>>
> >>>>>> >>>>
> >>>>>> >>>> --
> >>>>>> >>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> >>>>>> >>>> the body of a message to majordomo@vger.kernel.org
> >>>>>> >>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>>>> >>>>
> >>>>>> >>>
> >>>>>> >>>
> >>>>>> >>>
> >>>>>> >>> --
> >>>>>> >>>       Majed B.
> >>>>>> >>> --
> >>>>>> >>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> >>>>>> >>> the body of a message to majordomo@vger.kernel.org
> >>>>>> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>>>> >>>
> >>>>>> >>
> >>>>>> >
> >>>>>> >
> >>>>>> >
> >>>>>> > --
> >>>>>> >       Majed B.
> >>>>>> >
> >>>>>> --
> >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> >>>>>> the body of a message to majordomo@vger.kernel.org
> >>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>       Majed B.
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >>
> >
> >
> >
> > --
> >       Majed B.
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html