[dm-devel] [LSF/MM TOPIC] a few storage topics

Mike Snitzer snitzer at redhat.com
Tue Jan 17 20:06:12 UTC 2012


1) expose WRITE SAME via higher level interface (ala sb_issue_discard)
   for more efficient zeroing on SCSI devices that support it
   - dm-thinp and dm-kcopyd could benefit from offloading the zeroing to
     the array
   - I'll be reviewing this closer to assess the scope of the work

2) revise fs/block_dev.c:__blkdev_put's "sync on last close" semantic,
   please see Mikulas Patocka's recent proposal on dm-devel:
   http://www.redhat.com/archives/dm-devel/2012-January/msg00021.html
   - patch didn't create much discussion (other than hch's suggestion to
     use file->private_data).  Are the current semantics somehow 
     important to some filesystems (e.g. NFS)?
   - allowing read-only opens to _not_ trigger a sync is desirable
     (e.g. if dm-thinp's storage pool was exhausted we should still be
      able to read data from thinp devices)

3) Are any SSD+rotational storage caching layers that are being
   developed for upstream consideration (there were: bcache, fb's
   dm-cache, etc).
   - Red Hat would like to know if leveraging the dm-thinp
     infrastructure to implement a new DM target for caching would be
     well received by the greater community
   - and are there any proposals for classifying data/files as cache
     hot, etc (T10 has an active proposal for passing info in the CDB)
     -- is anyone working in this area?

4) is anyone working on an interface to GET LBA STATUS?
   - Martin Petersen added GET LBA STATUS support to scsi_debug, but is
     there a vision for how tools (e.g. pvmove) could access such info
     in a uniform way across different vendors' storage?

5) Any more progress on stable pages?
   - I know Darrick Wong had some proposals, what remains?




More information about the dm-devel mailing list