GFI (was Re: File systems are semantically impoverished...)

Alexander_Maryanchick%STORACTIVE@storactive.com
Thu, 24 Jun 1999 15:18:42 +0400


IMHO, some important problems were not still discussed here:
1. file forks already become oblolete.
a) For example, NTFS is a relational database.
It is impoverished compared to post-relational databases.
b) Moreover, treelike file system is obsolete itself.
Weblike file system is much more flexible.
c) UNIX FS support only few file types (regular, directory, FIFO)
ant 2 types of links (where are OS/2 'shadows'?)
d) some important UNIX structures (such as users) are not mapped to
FS.
2. Due to portability, modern file systems are used very RARELY.
Everybody having >1 OS will store his/her favorite files to the
FAT...
3. There are already many emulations of file forks:
IFF.
CORBA persistent storage.
even FAT file extensions.
even GIF is a LZW-compressed fork.

This situation is similar to situation in modern graphics hardware.
The best solution I know is GGI project.
Let me propose the GFI - General File Interface:

// user space
1. Modern software will communicate with file system
through the thin wrapper - libGFI.so
2. libGFI will redirect common requests to the "targets":
libEXT3, libFAT, libNTFS, libBFS...
using common features on ALL file systems.
(for example permitions on VFAT can be stored as in UMSDOS)
3. Old applications uses wrappers to libGFI:
for example libc4GFI.so instead of libc.so
3a. Note: _FEW_ applications such as 'cp' must be patched.
4. advanced libGFI functionality achieved by extensions:
libGFI-config ('registry'-like API based on FS! Dance, 'registry'
lovers!)
libGFI-DBS
libGFI-Type
etc...

// kernel space
The following operations can not be done in user space:
5. security
a) Even ACL is a regular fork,
it must be handled in kernel only.
b) directory locks (see 6b)
6. optimization for fork storage (ext3)
a) allow some small files must be stored in 1 inode
like BFS small nodes, NTFS resident attributes...
b) open directories.
use preallocated directory inode to open
"/very/long/directory/name/..../file"
as (inode)/file

May be I missed something, but I like and even need this
solution.
What is your opinion?

Best regards.
Alexander.

-
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/