Re: silent semantic changes with reiser4

Spam
2004-09-07T13:52:50Z

> Spam <spam@tnonline.net> writes:

>> > Additionally, files-as-directores does not solve the problem of
>> > "cp a b" losing named streams. There is curently no copyfile syscall
>> > in the Linux kernel, "cp a b" essentially does "cat a >b". So unless
>> > cp is modified we don't gain anything. If cp is modified to know
>> > about named streams, it really does not matter if named streams are
>> > accessed as file-as-directories, via openat(3) or via a shared library
>> > with some other interface.
>>
>> One suggestion is missed. It is to provide system calls for copy.
>> That would also solve the problem. Named streams and metas would
>> then be handled correctly. It also allows further changes to
>> filesystems without having to patch applications yet again.

> But this still solves only part of the problem. A backup application
> won't have any use for a copyfile syscall, it will need to be taught
> about streams.

Yes, but backup programs always needed to be taught about new
features. Be it new type of files, attributes or meta-data. I think
that teaching backup applications is far better than teaching every
application.

>> A copy system call would also be large beneficial for networked
>> filesystems (NFS, Samba, etc) as data wouldn't have to be
>> transferred over the network and back.

> Definitely.

>> Can we make a plugin infrastructure that will let user-space plugins
>> to be loaded for certain directories or files? If we can, then it
>> would present a much cleaner and easier way for the user to access
>> data he wants. In this particular example it was a tar file.

> In that case I'd argue that:

> mount -t userfs -o driver=tarfs foo /tmp/foo

> is a rather good kernel interface for plugins. userfs (or something
> based on userfs) is the plugin API and tarfs is a plugin. :-)

> To make this efficient, well have to allow non-root users to perform
> the mount syscall (with the limitation that they can only mount on top
> of directories they own and that the mounts have the nosuid and nodev
> flags set).

Yes, this seem to be one solution. It isn't very dynamic in usage
though. You can't use this directly from applications wihout
manually doing the mount.

This is only a solution to browsing contents of files. It doesn't
provide a solution for using meta-data streams or other things like
this.

~S

> /Christer