Fwd: Re: A common VFS and a Common conf-system [Part II]

[Dave Cridland]

On Thu Mar 10 02:24:56 2005, gtg990h at mail.gatech.edu wrote:
> Quoting Sean Middleditch <elanthis at awesomeplay.com>:
> > No, file naming and namespace at a very low level are OS concepts.  At a
> > higher level, there is the OS agnostic URI.
> 
> To the extent that URIs and file paths overlap, they are the same concept. When
> they overlap, file paths should be preferred. Otherwise, it'll just be
> confusing. If I've got a text file on my samba drive, I don't want to have to
> use "smb://foo/bar.txt" in gedit, and "/mnt/smb/foo/bar.txt" in my CLI.
> 

I don't want to have to use "smb" scheme URIs at all unless someone registers them. :-)

But in any case, I think URIs are a better naming system than filesystem paths. I can't take a filesystem path, stuff it into an email, and send it to anyone with the resonable expectation that it'll work.

> > The existing sycalls do not work.
> 
> I'm sure that's news to those people who've been using them for 30 years. The
> vast majority of computers today use a filesystem API that maps closely to
> POSIX. The paradigm might be inconvenient, but it's just wrong to say that they
> "do not work".
> 

For local filesystems, they do work, as you observe. For remote ones, they almost always don't. Which is why you get all manner of dire warnings about performing certain actions on certain remote filesystems.

open( ... , O_CREAT|O_EXCL ) is a hot favourite, as is locking.

I'd be willing to bet that the only URI scheme you'll get working with full POSIX semantics is NFS, because it was designed to be that way. And I'm not betting that anyone will get full POSIX semantics even there...

> > The OS itself does not support SSH.  if it does, the OS is scary and you
> > should stop using it, because it's probably also full of security holes
> > and other bad code...
> 
> I'm sure MacOS users will love to hear that.
> 

Mac OS X has SSH code in the *kernel*? Are you sure about that? I'd expect it to invoke userspace for that.

> > My solution is 100% in line with what you want, provides everything you
> > want, and provides it in a cleaner way.
> 
> Let's try to make this concrete. Would what you propose that would make D-VFS be
> "100% in line with what [I] want" resemble FUSE-KIO? Because everything in the
> current concept points in that direction. FUSE-KIO is exactly what I don't want,
> because it's a hack, and it's not transparent to CLI apps.
> 

Eh? I thought it was. Indeed, I thought that was the whole point of it.

> 
> > Imagine that you want to access an FTP share.  You need to enter a
> > password.  Are you suggesting that I type in,
> >
> > cat /remote/ftp/user at pass:server/pub/file.txt  ?
> 
> That's a trick question. The paths wouldn't have to auto-vivify. The cat would
> fail because /remote/ftp/server/pub wouldn't exist, and the user would have to
> mount the directory manually, using the existing mechanisms (like sshmount).
> That's consistent with the way things are now, and shouldn't confuse users.

Right... But... The way things are now, the user would run wget and drag the file locally. That doesn't confuse users either. Say there was a dvfs-load and a dvfs-save command which did the basic load/save with URIs. How is this less confusing?

> 
> Meanwhile, if the same path is accessed via the D-VFS API, the D-VFS daemon
> could handle the mount itself, and provide the password because presumably it
> knows it.

Or, alternately, it'd just access directly, because the kernel interface - if any - could be invoking a userspace daemon which happened to be the same thing as D-VFS.

BTW, a small question:

Given a URI "http://example.net/foo/bar/file.txt", how many round-trips will a kernel interface take, and how many will a purely userspace implementation take, to cat that file?

My guess is that a kernel implementation will take four - one per collection, and one for the file. A userspace implementation should take one - just a GET on the file.

Am I missing something, or would a kernel-layer be grossly inefficient?

Dave.