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