[ofiwg] Today's Data Storage and Data Access weekly meeting

[Cheng, Wendy]

TRIM could also be used in storage devices (e.g. capable of providing thin provision) other than SSD that may not have fixed physical block location and are constantly moving their blocks around for various reasons.  

Say a user delete a file .. internally the filesystem, sitting on the host end, may just update two blocks .. one on the directory block by removing the file entry and one on the resource bitmap to mark the free block range. The storage subsystem, sitting on the other end of storage link, has no idea of what just happened. The storage device would treat the deleted data blocks as valid and moving them around diligently. This brings in all sorts of issue ranging from free space depletion to write performance degradation .... until certain types of handshaking between the host and the device such as a TRIM command occurs.  

-- Wendy

> -----Original Message-----
> From: ofiwg-bounces at lists.openfabrics.org [mailto:ofiwg-
> bounces at lists.openfabrics.org] On Behalf Of Ryan, Jim
> Sent: Tuesday, November 18, 2014 9:47 AM
> To: Bernard Metzler; Paul Grun
> Cc: ofiwg at lists.openfabrics.org
> Subject: Re: [ofiwg] Today's Data Storage and Data Access weekly meeting
> 
> Re the discussion of the TRIM command, the following may be helpful:
> 
> 
> 
> 
> 
> 
> Trim (computing)
> 
> 
> From Wikipedia, the free encyclopedia
> 
>   (Redirected from TRIM)
> 
> Jump to: navigation, search
> 
> 
> For other uses, see Trim (disambiguation).
> 
> A Trim command (commonly typeset as TRIM) allows an operating system to
> inform a solid-state drive (SSD) which blocks of data are no longer considered
> in use and can be wiped internally.[1]
> 
> Trim was introduced soon after SSDs started to become an affordable
> alternative to traditional hard disks. Because low-level operation of SSDs
> differs significantly from hard drives, the typical way in which operating
> systems handle operations like deletes and formats resulted in unanticipated
> progressive performance degradation of write operations on SSDs.[2]
> Trimming enables the SSD to handle garbage collection overhead, which
> would otherwise significantly slow down future write operations to the
> involved blocks, in advance.[3]
> 
> Although tools to "reset" some drives to a fresh state were already available
> before the introduction of trimming, they also delete all data on the drive,
> which makes them impractical to use for ongoing optimization.[4] More
> recent SSDs will often contain internal idle/background garbage collection
> mechanisms that work independently of trimming; although this successfully
> maintains their performance even under operating systems that do not (yet)
> support Trim, it has the associated drawbacks of increased write amplification
> and wear of the flash cells.[5]
> 
> -----Original Message-----
> From: ofiwg-bounces at lists.openfabrics.org [mailto:ofiwg-
> bounces at lists.openfabrics.org] On Behalf Of Bernard Metzler
> Sent: Monday, November 17, 2014 10:31 PM
> To: Paul Grun
> Cc: ofiwg at lists.openfabrics.org
> Subject: Re: [ofiwg] Today's Data Storage and Data Access weekly meeting
> 
> I would be prepared to give a short tour through a list of requirements to
> integrate byte addressable storage into OFI but it might be more productive
> to have that call postponed a week in case attendance is low due to SC14 and
> Paul's an Sean's unavailability. We of course do not have a real quorum but
> missing at least two key contributors is a serious obstacle to me.
> 
> Best Regards,
> Bernard.
> 
> 
> 
> From:	Paul Grun <grun at cray.com>
> To:	"ofiwg at lists.openfabrics.org" <ofiwg at lists.openfabrics.org>
> Date:	11/18/2014 07:02 AM
> Subject:	[ofiwg] Today's Data Storage and Data Access weekly
> meeting
> Sent by:	ofiwg-bounces at lists.openfabrics.org
> 
> 
> 
> The agenda for today is a presentation by Bernad Metzler discussing network
> requirements to support byte addressable memory.
> I am unable to attend the meeting (trust me, you do not what whatever it is I
> have), so I would be grateful if someone could please take the role and
> capture a few minutes.  I am attaching the updated attendance sheet and a
> copy of last week’s minutes to use as a template.
> Regards,
> -Paul
> 
> Cray Inc.
> Office:    (503) 620-8757
> Mobile:  (503) 703-5382
>  [attachment "OFWG_DSDA_minutes_2014-11-11.docx" deleted by Bernard
> Metzler/Zurich/IBM] [attachment "OFWG_DSDA_attendence.xlsx" deleted
> by Bernard Metzler/Zurich/IBM]
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg