lkml.org 
[lkml]   [1999]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:5.503 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site