Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Private Namespaces for Linux 8

webword writes: "Dr. Dobbs is running a story by Ron Minnich on implementing private namespaces for Linux to solve problems in both distributed and cluster computing. This topic hasn't received as much attention as it should. I'm glad that someone published something intelligent and worth reading."
This discussion has been archived. No new comments can be posted.

Private Namespaces for Linux

Comments Filter:
  • by DrSkwid ( 118965 ) on Thursday November 29, 2001 @05:33AM (#2629815) Journal
    The private namespace is just one of the features of the plan9 operating system but it is by no means the most powerful.

    The 9p protocol is a universal protocol for file based operations and there is little distinction between local and networked machines but that is not the end of the story. plan9 has pushed the boundaries of "everything is a file".

    The cornerstone of this is the file server. A daemon that presents it's control and data as files in your namespace. The introductory fileserver in most texts is ftpfs.

    when you run it
    %ftpfs -a ftp.uk.freebsd.org

    it logs into the remote ftp server and then presents the file system there in your local namespace

    %ls /n/ftp
    /n/ftp/HEADER
    /n/ftp/bin
    /n/ftp/etc
    /n/ftp/pub
    %

    To access the files one uses the standard file manipulation tools.
    I'm sure you can see the power and potential of this.

    Once running ftpfs permits ANY program on your machine the ability to use files through the ftp protocol, and they don't have to know ANYTHING about ftp themselves, they just open, close, read & write files like they've always done.

    it means that to use tools like sed, grep, & awk on your remote files is a doddle, there's no shuffling the files around & risking sync trouble.

    Of course if it was just ftpfs then I'm sure you'd say "so what" but of course, it doesn't stop there. Writing a file server is fairly painless. All you need to do is implement the 9p protocol in your program. There's no mucking about with the kernel or fiddling with fstab.

    The network, like everything else, is presented as straight files.
    which means that even shell script can open network connections and process the results.
    I wrote a shell irc bot to prove the point
    http://www.proweb.co.uk/~matt/chugly.rc

    My next project is a fileserver for mounting a Postgres database connection as a file server. Once (if:) complete it will mean that ANY application will have the ability to access data in postgres DB's and manipulate the data using open, create, read & write.

    through an interface no more complex than :
    echo 'select * from webhits where date=''24-11-01'';' > /mnt/sql/ctrl
    cat /mnt/psql/recordset

    there's even more to plan9 and it's definately worth checking out

    http://plan9.bell-labs.com/plan9
    • I'll be certain to check this out, it sound cool.
      But I would like to point out one thing that isn't very good in hiding local/network calls from the programmers.
      There is a *lot* that can goes wrong in a network call that can't go wrong in a local call.
      Therefor, network calls should've options that allows me to check on what is going on in this call.
      Basically, this put you on unsynch-calls, which are much harder than straight calls.
      I certianly wouldn't like to do it for anything local.

      Question: What happens when there is an error in the fileserver and it crashes, how it affects the programs that uses it, and the system itself?
      • nothing is hidden from the programmer

        each process has it's own directory

        %ps | grep ftpfs
        matt 1168 0:00 0:00 124K Read ftpfs

        %cat /proc/1168/fd # give me a list of file descriptors this process has open

        /proc/612
        0 r c 0 0000000c.00000000 0 /dev/null
        1 w c 0 0000000c.00000000 0 /dev/null
        2 w M 27 00000001.00000000 32516 /dev/cons
        3 rw | 0 000010c1.00000000 1276 #|/data
        5 r c 0 00000004.00000000 368 /dev/bintime
        7 rw I 0 0002028d.00000000 1819 /net/tcp/20/data

        %ls /net/tcp/20
        /net/tcp/20/ctl
        /net/tcp/20/data
        /net/tcp/20/err
        /net/tcp/20/listen
        /net/tcp/20/local
        /net/tcp/20/remote
        /net/tcp/20/status

        %cat /net/tcp/20/status
        Established srtt 392 mdev 196 cwin 1752 swin 8760 rwin 65515 timer.start 6 timer.count 2 rerecv 0

        %cat /net/tcp/20/local
        192.168.1.9!21306

        %cat /net/tcp/20/remote
        195.182.165.1!21
        you don't hide things from the programmer, but you do hide the NEED of the programmer to implement ftp or the particular protocol
    • Doesn't this sound a little bit like kde's IO Slaves?

      They are more geared toward using them for application programming than shell access. KDE's IO subsystem treats the linux fs as one component our of many. I wonder if they have read about plan9's implementations?

      -pos
  • Take a look at, for instance, [PATCH][CFT] per-process namespaces for Linux [iu.edu]


    Code is findable at namespaces-S2.gz [psu.edu]; it looks like there are a number of newer versions, as we get gradually closer to 2.5.x properly forking off...

  • http://www.ddj.com/documents/s=1782/ddj0112a/0112a .htm

Mystics always hope that science will some day overtake them. -- Booth Tarkington

Working...