Re: [Patch v4 0/3] Introduce a driver to support host accelerated access to Microsoft Azure Blob

From: Greg KH <greg@kroah.com>
To: longli@linuxonhyperv.com
Cc: linux-fs@vger.kernel.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
	Long Li <longli@microsoft.com>
Subject: Re: [Patch v4 0/3] Introduce a driver to support host accelerated access to Microsoft Azure Blob
Date: Tue, 20 Jul 2021 17:54:23 +0200	[thread overview]
Message-ID: <YPbxr8XbK0IbD02r@kroah.com> (raw)
In-Reply-To: <1626751866-15765-1-git-send-email-longli@linuxonhyperv.com>

On Mon, Jul 19, 2021 at 08:31:03PM -0700, longli@linuxonhyperv.com wrote:
> From: Long Li <longli@microsoft.com>
> 
> Microsoft Azure Blob storage service exposes a REST API to applications
> for data access.
> (https://docs.microsoft.com/en-us/rest/api/storageservices/blob-service-rest-api)
> 
> This patchset implements a VSC (Virtualization Service Consumer) that
> communicates with a VSP (Virtualization Service Provider) on the Hyper-V
> host to execute Blob storage access via native network stack on the host.
> This VSC doesn't implement the semantics of REST API. Those are implemented
> in user-space. The VSC provides a fast data path to VSP.
> 
> Answers to some previous questions discussing the driver:
> 
> Q: Why this driver doesn't use the block layer
> 
> A: The Azure Blob is based on a model of object oriented storage. The
> storage object is not modeled in block sectors. While it's possible to
> present the storage object as a block device (assuming it makes sense to
> fake all the block device attributes), we lose the ability to express
> functionality that are defined in the REST API. 

What "REST API"?

Why doesn't object oriented storage map to a file handle to read from?
No need to mess with "blocks", why would you care about them?

And again, you loose all caching, this thing has got to be really slow,
why add a slow storage interface?  What workload requires this type of
slow block storage?

> Q: You also just abandoned the POSIX model and forced people to use a
> random-custom-library just to access their storage devices, breaking all
> existing programs in the world?
> 
> A: The existing Blob applications access storage via HTTP (REST API). They
> don't use POSIX interface. The interface for Azure Blob is not designed
> on POSIX.

I do not see a HTTP interface here, what does that have to do with the
kernel?

I see a single ioctl interface, that's all.

> Q: What programs today use this new API?
> 
> A: Currently none is released. But per above, there are also none using
> POSIX.

Great, so no one uses this, so who is asking for and requiring this
thing?

What about just doing it all from userspace using FUSE?  Why does this
HAVE to be a kernel driver?

thanks,

greg k-h