Re: Software RAID and TRIM

[NeilBrown <neilb@suse.de>]

On Wed, 29 Jun 2011 14:46:08 +0200 David Brown <david@westcontrol.com> wrote:

> On 29/06/2011 12:45, NeilBrown wrote:
> > On Wed, 29 Jun 2011 11:32:55 +0100 (BST) Tom De Mulder<tdm27@cam.ac.uk>
> > wrote:
> >
> >> On Tue, 28 Jun 2011, Mathias Burén wrote:
> >>
> >>> IIRC md can already pass TRIM down, but I think the filesystem needs
> >>> to know about the underlying architecture, or something, for TRIM to
> >>> work in RAID.
> >>
> >> Yes, it's (usually/ideally) the filesystem's job to invoke the TRIM
> >> command, and that's what ext4 can do. I have it working just fine on
> >> single drives, but for reasons of service reliability would need to get
> >> RAID to work.
> >>
> >> I tried (on an admittedly vanilla Ubuntu 2.6.38 kernel) the same on a two
> >> drive RAID1 md and it definitely didn't work (the blocks didn't get marked
> >> as unused and zeroed).
> >>
> >>> There's numerous discussions on this in the archives of
> >>> this mailing list.
> >>
> >> Given how fast things move in the world of SSDs at the moment, I wanted to
> >> check if any progress was made since. :-) I don't seem to be able to find
> >> any reference to this in recent kernel source commits (but I'm a complete
> >> amateur when it comes to git).
> >
> >
> > Trim support for md is a long way down my list of interesting projects (and
> > no-one else has volunteered).
> >
> > It is not at all straight forward to implement.
> >
> > For stripe/parity RAID, (RAID4/5/6) it is only safe to discard full stripes at
> > a time, and the md layer would need to keep a record of which stripes had been
> > discarded so that it didn't risk trusting data (and parity) read from those
> > stripes.  So you would need some sort of bitmap of invalid stripes, and you
> > would need the fs to discard in very large chunks for it to be useful at all.
> >
> > For copying RAID (RAID1, RAID10) you really need the same bitmap.  There
> > isn't the same risk of reading and trusting discarded parity, but a resync
> > which didn't know about discarded ranges would undo the discard for you.
> >
> > So is basically requires another bitmap to be stored with the metadata, and a
> > fairly fine-grained bitmap it would need to be.  Then every read and resync
> > checks the bitmap and ignores or returns 0 for discarded ranges, and every
> > write needs to check and if the range was discard, clear the bit and write to
> > the whole range.
> >
> > So: do-able, but definitely non-trivial.
> >
> 
> Wouldn't the sync/no-sync tracking you already have planned be usable 
> for tracking discarded areas?  Or will that not be find-grained enough 
> for the purpose?

That would be a necessary precursor to DISCARD support: yes.
DISCARD would probably require a much finer grain than I would otherwise
suggest but I would design the feature to allow a range of granularities.

NeilBrown
--
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