[Savannah-hackers] submission of Secure, Scalable Unicode Filesystem (UniFS) - savannah.nongnu.org

[jamesb . au]

A package was submitted to savannah.nongnu.org
This mail was sent to address@hidden, address@hidden


J. Buchanan <address@hidden> described the package as follows:
License: gpl
Other License: 
Package: Secure, Scalable Unicode Filesystem (UniFS)
System name: unifs
Type: non-GNU

Description:
There is no source code yet for this project, why will become clear in the 
description that follows.

UniFS (may be renamed GnuFS after consulting with rms, in progress) is a new 
free filesystem that scales to petabyte-sized storage devices, supports Unicode 
internally, is based on extents rather than clumsy indirect blocks, supports 
strong cryptography, compression, secure deletion of files, file slacks and 
directories, supports the creation of encrypted swap space for the host 
Operating System and may end up as a journaling filesystem.  A requirement of 
the filesystem is that it is self-healing and crash-proof.

The filesystem is organised into layers, with a *BSD and Linux compatible VFS 
and Gnu Mach/HURD compatible server interface (which hooks into the VFS layer, 
followed by the UniFS-specific layer, then a device-independent disk-driver 
layer, then a layer of glue code that interfaces directly with device drivers 
on the host Operating System.)

For compression, the UniFS will rely on GNU gzip, for strong cryptography, the 
GnuPG-derived libgcrypt (found on the GNU alpha server), for character set 
translation GNU iconv, and for the secure deletion, GNU shred (part of GNU 
fileutils/coreutils).

Designing a filesystem that is for the most part Operating System and machine 
independent is a mammoth task.  In particular, ensuring that the filesystem 
reaches its goal of scalability to petabyte sized secondary storage may be 
impossible in the near future (but it will be tested on terabyte sized 
storage.)  The architecture and specification of the filesystem is near 
complete, but coding will not commence until issues with the strong 
cryptography have been sorted out, for example storage of symmetric keys 
encrypted with public keys on disk extents or elsewhere on another filesystem, 
and how application programmes take advantage of this; and there is the issue 
of bypassing kernel page/buffer caches or implementing the filesystem's own 
buffer/page cache.

Here is a brief overview of the filesystem architecture:
[VFS/HURD server layer]
Provides mount/unmount, read/write, fsync, open/close, ioctl, etc system call 
stubs.
[UniFS layer]
Provides the filesystem functionality: on-disk structures shielded by the above 
platform-independent layers (VFS and HURD server interfaces), cryptography and 
compression, secure deletion, information needed by stat().
[Machine independent block I/O Layer]
Provides platform-independent interfacing to platform-dependent device drivers. 
 This layer must bypass the Operating System's virtual memory and cache 
mechanisms.
[Device driver layer]
Provides "glue code" to interface with the actual disk drivers, and possibly 
the filesystem's own buffer/page cache.  In porting the filesystem, only this 
layer and the top interface layer need be changed.

Initially documentation on the UniFS will be released (within the week).  
Articles and references will also be supplied and requests for 
comments/suggestions will be sought.  No developers will be accepted by the 
project until it begins the coding phase.

Other Software Required:
None that aren't already part of GNU, though it may use Diet libc instead of 
Gnu libc.  Diet libc is free software too.

Other Comments:
I have sent rms details of the filesystem and await his comments, and I'll keep 
the Savannah administrators updated on any progress.


_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/