Hello, Paolo. On Tue, Sep 11, 2012 at 07:56:53PM +0200, Paolo Bonzini wrote: > Understood; unfortunately, there is another major user of it > (virtualization). If you are passing "raw" LUNs down to a virtual > machine, there's no possibility at all to use a properly encapsulated
Is there still command filtering issue when you're passing "raw" LUNs down? > interface and still be able to pass sense data etc. back to the virtual > machine. And it's only going to grow now that people are starting to > use virtio-scsi. > > The set of use cases is so variable that no single filter can accomodate > all of them: high availability people want persistent reservations, NAS > people want trim/discard, but these are just two groups. Someone is > using a Windows VM to run vendor tools and wants to have access to > vendor-specific commands. > > You can tell this last group to use root, but not everyone else who is > already relying on Unix permissions, SELinux and/or device cgroups to > confine their virtual machines. You listed three - HA w/ persistent reservation, NAS w/ trim/discard and the third which you said that using root would be fine. Dunno much about persistent reservation but I don't see why trim/discard can't use existing block layer facilities whether from userland or virtio-scsi? > A generic filter (see > http://article.gmane.org/gmane.linux.kernel/1312326 for a proposal) > would be satisfactory for everyone, but it's also a major undertaking > and so far I've not received a single comment about it. Maybe I'm just not familiar with the problem space but I really hope things don't come to that. It's not like kernel by itself has to support every single possible use cases. > > So, it wouldn't be a good idea to abuse SG_IO filtering for exposing > > trim/discard. It's something which should be retired or at least > > severely restricted in time. I don't think we want to be developing > > new uses of it. > > > > I think trim/discards are fairly easy to abstract and common enough to > > justify having properly abstracted interface. In fact, we already > > have block layer interface for it - BLKDISCARD. If it's lacking, > > let's improve that. > > I do want to improve the block layer interfaces to avoid that people use > SG_IO. But unfortunately this is for a completely different use case. Hmmm? This was about discard, no? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
