Messages in this thread | | | From | rsinha@glue ... | Date | Sun, 20 Jun 1999 14:30:34 -0400 (EDT) | Subject | Re: FS Unions |
| |
the currently discussed BSD-based idea is very slick, but does not seem to deal with more than 2 or three partitions very well, being oriented as it is around the interrelationships between the primary and the secondary, not using some consistant model for ALL such relationships. The first method is prob easier to code, however it does lead to some problems so how about something similar:
layers.
(before you yell out "this is the same thing..." wait...)
there is a primary filesystem... by default it is the filesystem that owned the directory prior to the mount...
ie given the first mount to /home, the root partition would be primary..
this is overrideable using mount -p device # a new option to est primacy
this can be switched by the mount-point owner by using programs like tune2fs, though a shell-script wrapper with a name like fslayer
the point of being primary is that new files and dirs are by default created into this partition, and that in case of a file or dir having the same name, the primary partition one is shown...
the other partitions are added in as a queue, with the order being the determinate of which one's files take precedence...
to switch order, one simply types fslayer -l +1 devname to raise it one spot (ie from 4th to 3rd) fslayer -l -2 devname to move it in the other direction fslayer -l 1 devname to move it to the given position (primary position is 0, -1 is absolute bottom, newly mounted drives will take precedence) optionally one can refer to the layers by their layer locations, rather than the fully qualified device name instead of fslayer -l +1 /dev/hda1 one can use fslayer -l +1 _L4_ (if someone, in another context, wants to refer to a file called _L4_, (a) they are smoking something (b) they can put it in double quotes ie fslayer -whatever "_L4_" )
some may feel that the concept of a stack should be used rather than a queue... that the newest mount should by default take precedence... the arguement against this is that in this manner we are sure to prevent a change in the actions produced by binaries, etc.. unless we specifically want the primacy of the new dev... there are other security reasons as well
root can prevent the owner of a mount point from fooling around with the order by a fslayer -freeze...
optionally the order of partitions can be different for different directories... (optional in terms of implementation, this could be quite a headache to code...)
to move a given file from one layer to another, one types in mv (name of file) ._layerx/ mv ._layer3/foo . #moves foo from the fs that is fourth from the top to the primary partition...
the white space idea extends to this proposal... one can fslayer +ws (name of file/dir/whitespace) places a whitespace on the primary layer for the file.. fslayer +ws (name-of-file) (layerid) places the whitespace on the given layer (layerid can be the fully qualified device name, or the builtin reference shown earlier) placing a whitespace on a layer obscures only the layers beneath it. note that if the primary layer is given a whitespace and then it is moved, the whitespace goes with it, to whatever new location. to place a "floating whitespace" that obscures a file if it does not exist in the top layer WHATEVER THAT MAY BE AT THE TIME fslayer +ws (a
now to say that partitions are ordered in a specific manner, but you want some files from one part to rise or decend independant of the entire partition... all of these flags, values etc are being kept for partitions... I have to admit I am not sure where the currently discussed idea plans to place them, but that same location can have values for files independant of the partition value (performance for doing this could suck, but it prob will only be done in circumstances where performance is not the primary concern - that and implementation can be cleaned up, any ideas?) the values being x.y notation to establish where exactly they are being placed, relative to the partitions (and the -0.y is allowed, to allow files to rise above the primary partition)
thoughts? -RS
Rahul Sinha rsinha@glue.umd.edu ICQ# 9738191 AOL IM: vox deus Freshman Developer, Global Land Cover Facility Computer Science / Government Treasurer, UM Linux Users' Group University Of Maryland College Park Vice President, UM Debate Team
- 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/
| |