Messages in this thread | | | Date | Tue, 15 Jun 1999 13:03:14 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: FS Unions |
| |
On 15 Jun 1999, Stefan Monnier wrote:
> This intrusiveness is very bothersome. How about a different model > where the unionfs is really just a file-system that unions two others > (i.e. a total of 3 filesystems involved). This way, all the white-out > garbage can be kept in unionfs. Also the `move directory' could potentially > be dealt with by having the unionfs layer remember the move (basically, > unionfs would be a layer of redirection-pointers that originally > either point to a same-name node in fs1 or a same-name node in fs2, > and over time that would change by adding pointers to nowhereland > (white-outs) and pointers to different-name nodes in fs[12]. > > Of course, it might be better to make those redirection-pointers point > to several places at a time (if those places a re directories). > > To provide persistence, the unionfs would of course need some disk space, > which would probably be a file rather than a partition.
Great. Doing it in race-free way is your job, then. Deal? Locking issues in your scheme will be terrible, but if you want to do it - go ahead.
BTW, what for? Almost all filesystems can deal with the standard scheme in clean way. On the VFS level it *does* involve 3 filesystems, but providing any sort of persistence via separate *on-disk* filesystem or, worse yet, file will give you the shitload of races and/or deadlocks. Good luck fighting with them...
After all, you do not consider ->notify_change() intrusive, right? We could keep a separate on-disk fs containing permissions and ownership information, sure. Just look at UMSDOS and you'll see how much PITA it gives.
- 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/
| |