[lkml]   [2001]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFD] readonly/read-write semantics
    >>>>> "alexander" == Alexander Viro <> writes:


    viro> What we need is a "I want rw access to fs"/"I give up rw access"/"make
    viro> it ro" set of primitives. Unfortunately, it's even more compilcated -
    viro> e.g. fs may stomp its foot and set MS_RDONLY in ->s_flags (e.g. upon
    viro> finding an error if it has such policy). That DOESN'T look for files
    viro> opened for write (reasonable) and DOESN'T revoke write access to them.

    I really will like that thing for supermount, supermount tries to do
    that thing by hand, and it really fails because it is difficult,
    supermount tries to have the underlying fs unmounted if nobody has
    open files on it, and mounted rw only when somebody has a file opened
    on it and if someone has a file opened for write of there is happening
    any operation that needs write access. As we don't have an easy way
    to check if we are able to write in one filesystem (we can only use
    the IS_RDONLY() macro), it happens that I have to mount the filesystem
    rw for being able to call permission in that filesystem. Notice that
    permission don't need write access per se, but the IS_RDONLY() macro
    needs to have the filesystem mounted rw to fail. Yes, I can hack the
    macro to do the things that I need, but that means that everybody that
    needs that functionality will have to also hack it :(

    viro> Again, the main issue here is what do we want, not how to implement it.
    viro> Flame away.

    I will want a method is the inode/super_block (don't care which of
    them) for:
    - is_read_only_fs()?
    Notice that this method told as if we are able to have the
    fs rw, not necessarily that the fs is rw at the moment.
    - get_write_access()
    - put_write_access()

    Notice that there exist the functions get_write_access() and
    put_write_access() functions in the tree, and I will be really happy if
    there where a way to hook fs specific information there, as it will
    make a lot of the code in supermount really easy, and the same for
    other fs that need similar semantics.

    Later, Juan.

    In theory, practice and theory are the same, but in practice they
    are different -- Larry McVoy
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:01    [W:0.027 / U:28.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site