[lkml]   [2010]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation
On Fri, Nov 19, 2010 at 04:44:33PM +0100, Lukas Czerner wrote:
> >
> > But, oddly, it _is_ the default for mke2fs -t ext4,
> > which really threw me for a loop recently.
> >
> > I though my system had locked up when suddenly everything
> > went dead for a very long time (many minutes) while installing a
> > new system.

Yeah, the assumption was doing a single big discard (which is all
mke2fs is doing) should be fast. At least on sanely implemented SSD's
(i.e., like the Intel X25-M) it should be, since all that should
require is a flash write to the global mapping table, declaring all of
the blocks as free.

If there are some incompetently implemented SSD's out there which do a
flash erase of the entire SSD upon receiving a TRIM command (new
flash! Part of the whole *point* of a TRIM was to increase write
endurance by eliminating the need to copy blocks that really weren't
in use any more by the OS when the SSD is doing a GC copy/compaction
of a partially written flash sector), all I can do is do a sigh, and
wish that T13 had defined a "comptently implemented SSD bit" --- not
that Indilinix would admit if it they were incompetent. :-/

> That is exactly a reason why I posted a patch for
> "Make blkdev_issue_discard() interruptible", but nobody seems to care. As
> an addition I have patched mke2fs to inform user about ongoing discard,
> also with not much attention (Ted?).

Yeah, sorry. I'm still recovering from the kernel summit and
plumber's. I've got to get the critical bugfix patches out to Linus
before -rc3, and then I will try to get back to e2fsprogs.

- Ted

 \ /
  Last update: 2010-11-19 17:33    [W:0.114 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site