[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: Toronto Filsystem?
From:       "Albert D. Cahalan" <acahalan () cs ! uml ! edu>
Date:       1998-02-28 21:28:31
[Download RAW message or body]


Harald Milz writes:
>Stefan Reinauer (stepan@linux.de) wrote:

>> I heard there were some attempts to implement some kind of
>> Toronto Filesystem in Linux (Toronto is a "filesystem" which
>> allows mounting a rw-Device on top of a readonly directory
>> and all write accesses go to the rw-Device, so that
>> it`s possible to alter CDs or NFS-ro-mounted data locally.)
>
> There was an "inheriting filesystem" years ago, initially
> developed by Werner Almesberger AFAIK and heavily perused by
> the Unifix folks. Werner's IFS died, however, in the late .99's. 

I think that would require whiteout directory entries, as in UFS.
Directories become something like this:

struct ext2_dir_entry {
        __u32   inode;                  /* Inode number */
        __u16   rec_len;                /* Directory entry length */
        __u8    name_len;               /* Name length */
        __u8    flags;                  /* type code, and 4 other bits */
        char    name[EXT2_NAME_LEN];    /* File name */
};

The "flags" has i_mode>>12 and anything else interesting that will fit
(for example, hidden bits). File type values are as follows:

#define DT_UNKNOWN       0
#define DT_FIFO          1
#define DT_CHR           2
#define DT_DIR           4
#define DT_BLK           6
#define DT_REG           8
#define DT_LNK          10
#define DT_SOCK         12
#define DT_WHT          14

DT_UNKNOWN is for backwards compatibility. DT_WHT is whiteout, used
in the top filesystem to hide files on the read-only filesystem.
Files should not reappear when a directory is removed and recreated,
so there is an "opaque" attribute for them -- that is more efficient
than automatically filling the new directory with whiteout filenames.

I think this could get ugly when someone appends to a 1000 MB file.
You might want an inode hack that indicates "blocks in this file
before #345987 are specified by inode 42 on the layer below".

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

[prev in list] [next in list] [prev in thread] [next in thread]