Thread (20 messages) 20 messages, 4 authors, 2021-07-16

Re: [Patch v3 2/3] Drivers: hv: add Azure Blob driver

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2021-07-15 08:19:32
Also in: linux-doc, lkml

On Wed, Jul 14, 2021 at 09:14:13PM +0000, Long Li wrote:
quoted
Subject: Re: [Patch v3 2/3] Drivers: hv: add Azure Blob driver

On Tue, Jul 13, 2021 at 07:45:21PM -0700, longli@linuxonhyperv.com wrote:
quoted
From: Long Li <longli@microsoft.com>

Azure Blob storage provides scalable and durable data storage for Azure.
(https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fazu
quoted
re.microsoft.com%2Fen-
us%2Fservices%2Fstorage%2Fblobs%2F&amp;data=04%7
quoted
C01%7Clongli%40microsoft.com%7C950a81a410c54c2475a308d946ec0c09%7C
72f9
quoted
88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637618801920394272%7CUnk
nown%7C
quoted
TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
CJXVC
quoted
I6Mn0%3D%7C1000&amp;sdata=iLDP6EYsoCDlLvToJB31hIQxW3NdCnR0UH31
FRDwvRI%
quoted
3D&amp;reserved=0)

This driver adds support for accelerated access to Azure Blob storage.
As an alternative to REST APIs, it provides a fast data path that uses
host native network stack and secure direct data link for storage server
access.

So it goes around the block layer?  Why?
Azure Blob is object-oriented storage solution designed for cloud environments.
While it's entirely possible to go through block layer, it's not as efficient as using
its native APIs for data access. Some of the security features (authentication, 
tokens, lifecycle management) are not easily integrated into block layer. The
object model in Azure Blob is designed to be scalable and doesn't have many
limitations that block layer enforces (e.g. number of sectors).
What does the kernel's filesystem and block developers and maintainers
think about this end-run around that subsystem?  Do they agree with this
one-off-custom-ioctl api?  Who has reviewed this api to assure you that
it is sane and actually works properly?

And are you sure that the block layer is not efficient?  You just lost
all use of caching and io_uring and loads of other kernel infrastructure
that has been developed and relied on for decades.  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.

What programs today use this new api?  Where is the api published and
what ensures that it will remain stable?  What happens when it changes
over time, do we have to rebuild all userspace applications?  What
happens to the kernel code over time, how do you handle changes to the
api there?

You are going to need a lot of people to agree that this is ok to
circumvent in order to allow this to be accepted, have you done that
yet?
Please refer to this link for different storage models in Azure:
https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction#core-storage-services
Links are not good for changelogs as the kernel changelog is for
forever, while random company urls we have no control over.

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help