[Info-vax] Desirable features for VMS

Dan Cross cross at spitfire.i.gajendra.net
Fri Jan 26 14:42:17 EST 2024


In article <uounal$fvn$1 at panix1.panix.com>,  <kludge at panix.com> wrote:
>=?UTF-8?Q?Arne_Vajh=C3=B8j?=  <arne at vajhoej.dk> wrote:
>>On 1/25/2024 10:31 AM, Dan Cross wrote:
>>> Some sort of userspace pluggable filesystem support.
>>> FUSE, 9P + a mount driver, whatever.
>>
>>That would also be nice.
>>
>>But how many potential VMS users will consider "userspace
>>pluggable filesystem support" important in decision process?
>
>On production systems, I don't think it's all that useful for users to
>be able to mount and dismount filesystems, or to install their own new
>filesystem drivers of their own design.

Perhaps.  I worked on a system where applications were delivered
to prod as small ext4 filesystems that were accessed read-only
via iSCSI and mounted into a container with a ramfs overlay for
temporary files.

Such arrangements are common at e.g. hyperscalers.

>I -do- think that there is some security benefit in having the filesystem
>support in user space, but I also think the performance penalty is usually
>not worth it.

There's a fair amount of prior art here that shows decent
performance.  Plan 9, for example, implemented the window system
as a file system.  For that matter, the graphics device was
exposed as a filesystem as well, though that was in the kernel.

>What -would- be useful would be the ability to plug new filesystems easily
>into the kernel, along with ntfs and various fat drivers supplied as needed.
>Do I need to be able to do this dynamically from user space?  Not really.

YMMV.  It's been my experience that once you go down the route
of allowing it, however, you find surprising application areas
and it's actually very useful.

Enough to wrangle new customers?  No, not likely.

	- Dan C.




More information about the Info-vax mailing list