Re: [9fans] Additional compilers under 9vx.OSX
In article 90f71fcedeb5b45a5bed515862b8a...@hamnavoe.com, Richard Miller 9f...@hamnavoe.com wrote: 1) If it is upgraded to latest version of Snow Leopard (I think 10.6.3?), will anything regarding 9vx.OSX break? As far as I can tell, 9vx works fine on MacOSX 10.6.7. Just a note that we've since upgraded to 10.6.7 and it seems fine with us too. -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Re: [9fans] Additional compilers under 9vx.OSX
In article inuqri$eqi$1...@panix1.panix.com, Greg Comeau com...@comeaucomputing.com wrote: In article insdeo$km5$1...@panix1.panix.com, Greg Comeau com...@comeaucomputing.com wrote: As mentioned in a post yesterday, we seem to have succeeded in getting 5c et al built. However, in resuming playing around at least one case /bin/ape/sh is producing: ./command-name[3]: other-command-name: cannot execute - Access Denied since doing the mk's. Obviously something in those builds stomped on something already existing. Any ideas what? I found something similar online and did what they suggested: cd /sys/src/ape and mk nuke and mk install, but same result as above, even after rebooting. ?? FYI FWIW, I was able to locate binaries in the install file that the original /386/bin/ape directory came from and so I reexpanded it to a new directory and overrode the rebuilt one with a bind, and all now appears well. So instead of re-installing 9vx and/or trying to build only the 5? commands (which I think would have worked since it shouldn't have effected sh), I'm going to let good enough be for now. Will test some more, but I can only assume some sort of versionitis came into play here. -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Re: [9fans] Q: moving directories? hard links?
On 04/16/11 23:49, Skip Tavakkolian wrote: Linux has slowly become Windows-lite Whatsoever it is, though GNU sucks, but the GNU/Linux is dominating the markets: http://mybroadband.co.za/news/software/19762-The-Linux-Microsoft-war-over.html -- Balwinder S bdheeman DheemanRegistered Linux User: #229709 Anu'z Linux@HOME (Unix Shoppe)Machines: #168573, 170593, 259192 Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP Home: http://werc.homelinux.net/ Visit: http://counter.li.org/
Re: [9fans] Q: moving directories? hard links?
erik quanstrom quans...@quanstro.net writes: It's not that obvious to me. A hard link is another name for a file, uniquely identified by type,device,qid. how do you specify the device? you can't without giving up on per-process-group namespaces. i don't think there's any way to uniquely identify a device except through a namespace, and there's no global namespace. I got the impression, from what I read, that the kernel driver chooses the device number. I don't understand why 9P doesn't allow transporting bind operations from machine to machine like this. this is done all the time. every time you cpu, you are exporting your whole namespace to the target machine. Then what's all that about in paragraphs 2-3 on p. 21 of /sys/doc/9.ps? It's similar for moving directories. If you have a 10 GiB directory, please explan why a bind is not appropriate here? The old directory will still be visible in its old location, even if it's bound to a new name. I had thought about sticking all my files under $home/files/ and binding them where I wanted them. But then, I'd just be reinventing all the i-node stuff of *nix. I might as well just call the directory $home/inodes/. :) At $local_big_networking_corp, I got chewed out for copying a 650MB ISO across a single router. did the router get tired? Yeah, I didn't understand their reaction, either. -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Q: moving directories? hard links?
On Thu, Apr 21, 2011 at 8:32 AM, smi...@zenzebra.mv.com wrote: I got the impression, from what I read, that the kernel driver chooses the device number. what's a device number and why would we need one? ron
Re: [9fans] Q: moving directories? hard links?
Bakul Shah ba...@bitblocks.com writes: Ask yourself *why* do you need it. Is it just convenience (what you are used to) or is there something you do that absolutely requires hard links? Next compare the benefit of hardlinks to their cost. It is worth it? I'm trying to create a data structure in the form of a directed acyclic graph (DAG). A file system would be an ideal way to represent the data, except that P9 exposes no transaction to give a node more than one name. I could store the data in a P9 file system tree and maintain a set of links in, say $home/lib/bindrc.d/myDAG. But, every time I copy/relocate/distribute the tree, I would have to include the myDAG bindings. It would be much nicer if the structure of the data embodied in the data itself. ATM, I'm thinking about creating a DAGfs backed by pq. That way, standard file utilities could still be used be used to manipulate the data. However, that solution strikes me as being suspiciously similar to creating a new disk file system. (How many do we have, already?) -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Q: moving directories? hard links?
On Thu, Apr 21, 2011 at 8:44 AM, smi...@zenzebra.mv.com wrote: I'm trying to create a data structure in the form of a directed acyclic graph (DAG). A file system would be an ideal way to represent the data, except that P9 exposes no transaction to give a node more than one name. warning: i'm going to try to talk about graphs. This usually ends in tears. A file system is a DAG I believe. There is way to give something more than one name: mkdir in the directory that contains it, it has the name you give it. cd into it, and as far as you're concerned it has the name '.'. Is this enough? ron
Re: [9fans] Q: moving directories? hard links?
On Thu, 21 Apr 2011 15:44:32 - smi...@zenzebra.mv.com wrote: Bakul Shah ba...@bitblocks.com writes: Ask yourself *why* do you need it. Is it just convenience (what you are used to) or is there something you do that absolutely requires hard links? Next compare the benefit of hardlinks to their cost. It is worth it? I'm trying to create a data structure in the form of a directed acyclic graph (DAG). A file system would be an ideal way to represent the data, except that P9 exposes no transaction to give a node more than one name. A FS is not necessarily the ideal way. I could store the data in a P9 file system tree and maintain a set of links in, say $home/lib/bindrc.d/myDAG. But, every time I copy/relocate/distribute the tree, I would have to include the myDAG bindings. It would be much nicer if the structure of the data embodied in the data itself. ATM, I'm thinking about creating a DAGfs backed by pq. That way, standard file utilities could still be used be used to manipulate the data. However, that solution strikes me as being suspiciously similar to creating a new disk file system. (How many do we have, already?) Not a disk FS, just a naming FS. You can overlay your naming FS on top of an existing disk based FS. In effect each named file in this naming FS maps to a canonical name of a disk based file. You can implement linking via a ctl file or something.
Re: [9fans] Q: moving directories? hard links?
You can overlay your naming FS on top of an existing disk based FS. In effect each named file in this naming FS maps to a canonical name of a disk based file. You can implement linking via a ctl file or something. Is lnfs(4) a relevant example?
Re: [9fans] Q: moving directories? hard links?
On Thu, 21 Apr 2011 21:17:21 BST Richard Miller 9f...@hamnavoe.com wrote: You can overlay your naming FS on top of an existing disk based FS. In effect each named file in this naming FS maps to a canonical name of a disk based file. You can implement linking via a ctl file or something. Is lnfs(4) a relevant example? Seems so. IIRC companies such as Panasas separate file names and other metadata from file storage. One way to get a single FS namespace that spans multiple disks or nodes for increasing data redundancy, file size beyond the largest disk size, throughput (and yes, complexity). Along these lines, a bit torrent swarm would make for an interesting experiment in distributed filestorage.
Re: [9fans] Q: moving directories? hard links?
IIRC companies such as Panasas separate file names and other metadata from file storage. One way to get a single FS namespace that spans multiple disks or nodes for increasing data redundancy, file size beyond the largest disk size, throughput (and yes, complexity). that certainly does seem like the hard way to do things. why should the structure of the data depend on where it's located? certainly ken's fs doesn't change the format of the worm if you concatinate several devices for the worm or use just one. - erik
Re: [9fans] Q: moving directories? hard links?
On Thu, Apr 21, 2011 at 3:41 PM, erik quanstrom quans...@labs.coraid.com wrote: IIRC companies such as Panasas separate file names and other metadata from file storage. One way to get a single FS namespace that spans multiple disks or nodes for increasing data redundancy, file size beyond the largest disk size, throughput (and yes, complexity). that certainly does seem like the hard way to do things. why should the structure of the data depend on where it's located? certainly ken's fs doesn't change the format of the worm if you concatinate several devices for the worm or use just one. This would be a long discussion :-) best bet is to read Gibson's stuff. ron
Re: [9fans] Q: moving directories? hard links?
On Thu, 21 Apr 2011 16:17:50 PDT ron minnich rminn...@gmail.com wrote: On Thu, Apr 21, 2011 at 3:41 PM, erik quanstrom quans...@labs.coraid.com wrote: IIRC companies such as Panasas separate file names and other metadata from file storage. One way to get a single FS namespace that spans multiple disks or nodes for increasing data redundancy, file size beyond the largest disk size, throughput (and yes, complexity). that certainly does seem like the hard way to do things. why should the structure of the data depend on where it's located? =A0certainly ken's fs doesn't change the format of the worm if you concatinate several devices for the worm or use just one. This would be a long discussion :-) best bet is to read Gibson's stuff. Indeed. On Isilon's website we find: * Up to 10.4 petabytes and up to 85 GBps of throughput and up to 1.4 million IOPS in a single file system. * Add capacity and/or performance within 60 seconds. I don't know how Isilon does this but think of how one would build a FS that can scale to multi perabyte files requiring multi gigabyte/sec bandwidth and ability to add storage as needed. Think oil companies and movie studios!
Re: [9fans] Q: moving directories? hard links?
that certainly does seem like the hard way to do things. why should the structure of the data depend on where it's located? certainly ken's fs doesn't change the format of the worm if you concatinate several devices for the worm or use just one. This would be a long discussion :-) best bet is to read Gibson's stuff. could you please clarify? i'm not following along. - erik
Re: [9fans] Q: moving directories? hard links?
On Thu, Apr 21, 2011 at 4:55 PM, erik quanstrom quans...@quanstro.net wrote: could you please clarify? i'm not following along. I'm at the end of a long day and not able to write a good explanation of what they are thinking. :-) ron
Re: [9fans] Q: moving directories? hard links?
On Thu Apr 21 20:01:54 EDT 2011, rminn...@gmail.com wrote: On Thu, Apr 21, 2011 at 4:55 PM, erik quanstrom quans...@quanstro.net wrote: could you please clarify? i'm not following along. I'm at the end of a long day and not able to write a good explanation of what they are thinking. :-) no problems. - erik
