Messages in this thread | | | Date | Tue, 15 Jun 1999 05:51:45 +0100 | From | Jan-Simon Pendry <> | Subject | Re: FS Unions |
| |
Alexander Viro wrote: > > [ good explanation of create/delete process ... ] > > > To create a fully-realized implementation, would there have > > to be modifications to commands or facilities to take into account > > or exploit the fs unions? If so, this might be a way for some others > > mount(8), umount(8) and fsck(8). Mount should be taught to deal > with the new flag, fsck should be taught to that whiteouts are valid > entries. Other than that... Some utility to find and remove whiteouts.
just to summarise, the top level filesystem requires the following (additional) functionality:
1. persistent representation of a whiteout node. 2. persistently mark a directory non-transparent. 3. return list of whiteouts in a directory. 4. create a named whiteout. 5. remove a named whiteout.
all apart from #1 must also be accessible via system call interfaces.
underlying filesystems require no modifications.
user-level changes are:
1. change opendir et al. to deal with whiteouts. 2. change file-tree walker to deal with whiteouts. 3. add options to rm, ls and find to handle whiteouts. 4. teach fsck about specific storage implementation of whiteouts. 5. provide backup/recovery hooks.
note that the bsd implementation provides backup/recovery using dump/restore. dump/restore correctly handle whiteout nodes. tar, pax etc. have no knowledge of whiteouts.
jan-simon.
- 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/
| |