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