Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268056AbUIGNwu (ORCPT ); Tue, 7 Sep 2004 09:52:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268067AbUIGNwu (ORCPT ); Tue, 7 Sep 2004 09:52:50 -0400 Received: from c002781a.fit.bostream.se ([217.215.235.8]:53641 "EHLO mail.tnonline.net") by vger.kernel.org with ESMTP id S268056AbUIGNwn (ORCPT ); Tue, 7 Sep 2004 09:52:43 -0400 Date: Tue, 7 Sep 2004 15:52:25 +0200 From: Spam Reply-To: Spam X-Priority: 3 (Normal) Message-ID: <16310505631.20040907155225@tnonline.net> To: Christer Weinigel CC: David Masover , Horst von Brand , Tonnerre , Linus Torvalds , Pavel Machek , Jamie Lokier , Chris Wedgwood , , Christoph Hellwig , Hans Reiser , , , Alexander Lyamin aka FLX , ReiserFS List Subject: Re: silent semantic changes with reiser4 In-Reply-To: References: <200409070206.i8726vrG006493@localhost.localdomain> <413D4C18.6090501@slaphack.com> <1183150024.20040907143346@tnonline.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2673 Lines: 68 > Spam 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/