What is TCFS?

TCFS is a cryptographic network file system for group sharing of encrypted files. Because of a more advanced architecture between the encryption and the OS-files, TCFS is completely transparet to the enduser. TCFSl encrypts files even before sending them to the fileserver and will de-crypt them before nefore beeing read by any softwareapllication. The encryption/ decrypt- is beeing done only on the client-site. So no data will be transfered over the network in not encrypted-form. This also includes for the encryption keys.

 

Here an attempt to autoexract some (inline)-documentation, buggy, please check again later!!

TCFS_MAX_DIRCACHE controls the number of simultaneously cached directory chunks. Each chunk holds the list of tcfs_entry's returned in a single readdir call in a memory region of size PAGE_SIZE. Note that at most server->rsize bytes of the cache memory are used.

The upper limit on timeouts for the exponential backoff algorithm.

Size of the lookup cache in units of number of entries cached.
It is better not to make this too large although the optimum
depends on a usage and environment.
This struct describes a file region to be written.
It's kind of a pity we have to keep all these lists ourselves, rather
than sticking an extra pointer into struct page.
Definitions of the bits in an Internet address integer.
On subnets, host and network parts are found according
to the subnet mask, not these masks. INET An implementation of the TCP/IP protocol suite for the LINUX operating system. INET is implemented using the BSD Socket interface as the means of communication with the user level.

Definitions of the Internet Protocol. Definitions of the bits in an Internet address integer. On subnets, host and network parts are found according to the subnet mask, not these masks.
It's silly to have NR_OPEN bigger than NR_FILE, but I'll fix that later. Anyway, now the file code is no longer dependent on bitmaps in unsigned longs, but uses the new fd_set structure..

Some programs (notably those using select()) may have to be
recompiled to take full advantage of the new limits..
Note that read-only etc flags are inode-specific: setting some file-system flags just means all the inodes inherit those flags by default. It might be possible to override it selectively if you really wanted to with some ioctl() that is not currently implemented.
Try to keep the most commonly used fields in single cache lines (16 bytes) to improve performance. This ordering should be particularly beneficial on 32-bit processors.

We use the first 16 bytes for the data which is used in searches over the block hash lists (ie. getblk(), find_buffer() and friends).

The second 16 bytes we use for lru buffer scans, as used by sync_buffers() and refill_freelist(). This is the "filldir" function type, used by readdir() to let the kernel specify what kind of dirent layout it wants to have. This allows the kernel to read directories into kernel space or to have different dirent layouts depending on the binary type. This is called from the tcfs_ioctl (to set the flags or the ciphername) and from the write function (for the file size).
It will encrypt/decrypt a file or a dir (i.e. the filenames) according to the flags, if called from tcfs_ioctl.
We do it like this: When a (user) process wishes to write data to an
TCFS file, a write request is allocated that contains the RPC task data plus some info on the page to be written, and added to the inode's write chain. If the process writes past the end of the page, an async RPC call to write the page is scheduled immediately; otherwise, the call is delayed for a few seconds.

Just like readahead, no async I/O is performed if wsize < PAGE_SIZE.

Write requests are kept on the inode's writeback list. Each entry in
that list references the page (portion) to be written. When the
cache timeout has expired, the RPC task is woken up, and tries to
lock the page. As soon as it manages to do so, the request is moved from the writeback list to the writelock list.
Note: we must make sure never to confuse the inode passed in the write_page request with the one in page->inode. As far as I understand it, these are different when doing a swap-out.

To understand everything that goes on here and in the TCFS read code, one should be aware that a page is locked in exactly one of the following cases:
- A write request is in progress.
- A user process is in generic_file_write/tcfs_update_page
- A user process is in generic_file_read

Also note that because of the way pages are invalidated in
tcfs_revalidate_inode, the following assertions hold:

- If a page is dirty, there will be no read requests (a page will
not be re-read unless invalidated by tcfs_revalidate_inode).
- If the page is not uptodate, there will be no pending write
requests, and no process will be in tcfs_update_page.
FIXME: Interaction with the vmscan routines is not optimal yet.
Either vmscan must be made tcfs-savvy, or we need a different page reclaim concept that supports something like FS-independent buffer_heads with a b_ops-> field.
The following implementation of the base64 decoding might look a bit clumsy but I only try to follow the POSIX standard:
``All line breaks or other characters not found in the table
[with base64 characters] shall be ignored by decoding
software.''

Declare the space requirements for TCFS arguments and replies as number of 32bit-words/ Common TCFS XDR functions as inlines. We need to translate between tcfs status return values and the local errno values which may not be the same.