[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