Messages in this thread | | | From | "Tan Pong Heng" <> | Subject | RE: (reiserfs) File conglomerations | Date | Wed, 30 Jun 1999 09:01:22 +0800 |
| |
After listening for so long, I came to the following "conclusions" - 2 of them: 1) Whether it should be done? 2) How it should be done?
The first question can only be answered after you are clear why you want to do it. So far, I have seen only one "justification" - programmer implementing structure store themselves. For this, we have to understand why structure stores were introduced in the first place. It seems rather clear that in most cases, structure stores could be replaced with directory trees - except for on aspect - you still want to treat the structure store as one entity and handle as such. You want to be able to identify, copy, delete, and operate on a structure store as a file. The file aggregation extension proposed would meet most of these requirements. But, there is still two other important aspects - portability and the ability to reverse the aggregation operation. The application programmer implement their own structure store so that they can ensure that the file is portable across operating systems. Implementing this as a file system extensions specific to Linux does not meet this requirement. Another problem is that, file aggregation can be done easily, but the reverse is rather hard to do correctly. For example, if you use tar to aggregate, does that mean that when a tar file is copied in, you untar it automatically? If you don't, you can not preserve the semantics. As such, until a good answer for these issues surface, there is no real reason to rush into this.
Even if you want to do it, whether within a file system such as RiserFS is the right place to implement it is another important question. Please note that these functionality should not be specific to any file system - why can't I have it on top of NFS, E2FS, VFAT, etc? The current "design" of the UNIX FS is that there is a VFS layer and the underlying FS layer. The underlying FS layer implement the layout of FS on the physical devices - and it is their jobs to do this well. In that aspect, RiserFS has proven to have done it reasonably well. The proposed functionality really has nothing to do with the physical layout. It should be implemented in the VFS layer. Or at least in a layer in between the existing two. In this way, the extension will be available to other FS too. Actually, I am considering to do it this way for the Crypto FS extension too. After all, why should it be limited to extending the NFS as in TCFS and CFS?
Regards, Tan Pong Heng
-----Original Message----- From: Lou Grinzo [mailto:lgrinzo@stny.lrun.com] Sent: Tuesday, June 29, 1999 11:18 PM To: linux-kernel@vger.rutgers.edu; reiserfs@devlinux.com Subject: (reiserfs) File conglomerations
I must be insane to be still tilting at this windmill, but I have to give this one last shot.
File conglomerations (albods, whatevers) is a very promising idea, but no matter how you approach it, it has an impact on file system semantics, which is a very serious change to any operating system. Such changes should never be made without a clear idea of what the goals are, and exactly how the system should look and work.
The issues I personally would like to see addressed include:
What benefits will this provide to the user working at a command line? What about a user running a GUI? Be specific, and think like a user, i.e. someone who is primarily interested in getting work done with the best combination of efficiency, ease of use, security, and stability possible.
What are the benefits to a sys admin? Again, "be the admin" for the purpose of this answer.
What benefits will this provide to programmers? Convince me as a Linux app. programmer that this is something I want to spend the time to learn how to use, and then actually support in my programs. What capabilities does this add to my toolkit, or what does it improve that I can already do?
At each of the 3 key interfaces (CL, GUI, API), will file conglomerations always look like directory trees? Will they never look like directory trees? Or will they look like either, depending on semantic details? (E.g. use old file system calls to treat the cong. as a single file, but use a new call to treat it as a directory.) (IMO, the ability for the user to take an entire dir, tree of files and treat it as a single file (to move it to another system, for example) without having to resort to tar or any other special handling could be the biggest single end-user benefit of file cong.)
Will file cong. be supported under all the FS's that Linux currently supports, and to an equal extent? If not, exactly how will this work with various FS's, as viewed by the three interfaces (CL, GUI, API)? (I'm not implying that a "no" answer to the first question in this paragraph means don't add cong.)
What about changes to basic commands? Will any be needed to support dealing with a cong. as a single file vs. a directory? (It's very tempting to ignore this issue, and only discover afterwards that you've added a feature that has created a huge demand for "little" changes in dozens of commands. If it's deemed that this level and pervasiveness of change is acceptable, fine, but it's another detail that should be decided now and explicitly, not after the feature is rolled into major distributions and the issue is forced.)
Will a CL user be able copy/move/delete/rename a cong. as a single entity without resorting to explicitly creating an archive of the cong.'s contents with tar or something similar?
Will Windows NT cong. be treated like Linux cong., will they continue to be visible only as single binaries? (As Linux grows in mainstream usage, it will increasingly be used in mixed-mode environments on the desktop, making this a far more relevant issue.)
Will this change entail tradeoffs in terms of system performance, usability, complexity, etc.? If so, what are they likely to be?
Will this support be modular enough that a user or enterprise can choose not to use it and have zero impact on the system? In other words will it be "ignorable"?
Will cong. have passwords? (Have to use the PW to mount it, and then it's a normal part of the FS.) Will cong. support compression? Encryption? (Yes, this is getting a bit blue-sky, but if it is decided that these features are definitely desirable, then it only makes sense to ensure that today's design is flexible enough to accommodate them when the time comes to add them.)
Will security attributes be set for individual files in the cong., for the cong. as a whole, or both--default settings at the cong. level, overridden by those of individual files?
Will cong. support scripts/binaries that are stored in the cong. and automatically run when the cong. (not the FS that contains it) is mounted and unmounted? (There are some interesting possibilities here for software installation and de-installation, since this would provide most of the support for a very user friendly "software cartridge" architecture, something I've been working on the design of for a while.)
Before anyone tries to lynch me, let me point out that in my experience in operating system and application design and programming, the two most valuable lessons I learned are that 1) too centralized and strict control over a software design is deadly, and 2) too little control is even worse than too much. The "right" amount of control is highly dependent on the nature of the project. Adding file cong. has many ramifications for the rest of the system, and requires a lot of up-front scrutiny, IMO, to add what's really needed, as well as to avoid problems in the future.
I also want to say that I have a lot of respect for the Linux programmers and the distributed development model. I'm not in any way advocating a replacement for the current system. I'm proposing an extension of it to include a slightly more coordinated, and, hopefully, more complete and efficient analysis of requirements and the high-level design.
As I've said before, if it appears that I can help the process by acting as an administrator to help spell out the issues and document the answers as you provide them, then I'll gladly volunteer and provide the web space.
Lou
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |