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/