Actually this thing would have melted down and cried in the face of Weta's storage needs, just because it's dense doesn't mean it's fast. You need lots of spindles, and 4 doesn't count. The average FibreChannel disk is good for maybe 200-300 ops per second, so you really want lots of 'em.
They use a mix of NAS and DAS storage, I belive the DAS consists mainly of SGI stuff using XFS and CXFS, while the NAS stuff is all NetApp Filers which can have hundreds of disks
The usual connector types are HDSC (?) and DB9 (though this only uses 4 pins)
Copper makes a lot of sense for many fibrechannel uses. Connect multiple disk shelves together is the most common, since this only requires 1 foot cables, and copper is much more sturdy than optical, and lower cost for the connecters/interfaces.
Obviously there are limits to what copper can do, the most noticable is the 30M limit.
LFS (originally by Ousterhout, ported to 4.4BSD by Seltzer) writes everything in a log. Just write as much as possible in one long stripe to the disk (up to a meg in the initial designs.) This means blocks of data move each time they are updated, which means you always write new inodes with each data write which point to the old unchanged blocks, and the new changed blocks.
Obviously once you hit the end of the disk, you have to wrap back around, and write some more, but where?
LFS had a seperate backgroup process that went around and finds all the, now unneeded, old data blocks that have been rewritten somewhere else and cleans them up. This is called the cleaner. Once the cleaner has found more space you get to write there.
The main positive point of the LFS design was very good write performance due to the lack of seeking needed to put little bits of data all over the disk.
The main downside to LFS was the cleaner itself, which was costly to run.
Margo Seltzer and Trevor Blackwell did some more work with the cleaner in this paper that shows that with the right timing you can get the cleaner to run efficiently.
I'm not aware of this work having been implemented (at least not as of 2000 which I stopped working on it on BSDI where Margo had been keeping LFS)
A good description can be found in the original papers, and the Pink 4.4 BSD book by McKusick, Bostic, Karels, and Quaterman.
The software iscsi initiator for linux can be used with PXE to build a diskless iscsi sysstem. I've been running a diskless linux box for my primary work station for about 2 months.
2x the speed of my old ide drive, and i'm just using 100mbit ethernet.
Call it the Big Brother of introductory computer science courses--always watching, anticipating students' every move, a little mysterious.
Every year, students in Computer Science 50: "Introduction to Computer Science" (CS50) debate whether the course's instructors really use a special program to weed out cheaters and plagiarists.
But the software is real, instructors say--and it is highly effective in tracking cheating.
"I always have students who say to me, 'Do you really have a software that checks for cheating?'" says Gordon McKay Professor of Computer Science Stuart M. Sheiber, who teaches CS50. "They think we're making this up to put the fear of God in them."
Actually the I/O bandwidth of an SSD is limited by
the fact that many of them have SCSI internally, and even if they have FC back ends you'll only get 35MB throughput, but latency is nice.
a slashdotted server would be probably dealing with a small enough amount of data that it would all be in host buffer cache.
Harvard also uses this for it's undergrad OS class.
It's certainly not a microkernel though. It's a monolithic kernel running on a MIPS emulator that doesn't have any real device driver system. Granted device drivers aren't really worth teaching in an OS internals class.
Yes, the lack of kernel memory allocation is the single major problem with NachOS. Yes, i need a new kernel data structure, ok 'New...' Some friends of mine will say there are some evil heisenbugs in their code as well, but I don't believe them:). Oh and a couple of really obscure MIPS emulation issues, which I was too lazy to fix.
But yes, NachOS to start, and BSD after that is a very good route in my opinion (some would say OSF1 based on the number of papers that have been published from it as well, though you have to wonder about all those CMU, and MIT people;)
In my OS class (and at other schools like UC Berkeley, Duke, and Harvard) we used a package called NachOS. It runs on a MIPS emulator, and you write large chunks of the OS yourself. We had to write processes, system calls, filesystems, VM, schedulers, applications for the OS (the shell was just 5% of assignment 2). The final assignment is to write a couple different schedulers or other subsystem, then performance analyize the hell out of it, which was really interesting.
Granted this course has a reputation for being WICKED hard. The whole OS is multi-threaded etc etc, so you have to deal with all the fun race condition issues just like a real OS. Running on a simulator makes life much better for a couple of reasons. 1) crash/rebuild/restart/debug cycle is MUCH FASTER. 2) debugging real kernels w/o having two machines (for serial debugging) is not fun, plus you've got to have the machines for the students, which can be a pain. 3) come on, device drivers aren't the _interesting_ part of the OS, so using a system where thats already done is more useful.
I liked doing this better than what other people here have suggested. I think just writing a device driver is kinda silly. It's a reasonably straight forward project, not really a good thing to do in an OS course, having students working with all the important OS components is much more useful. Starting with Linux is not a very good idea because of the large code base, and from what I've seen it's not really the best code for students to read. I would recommend one of the BSDs if you really want to go with the whole OS paradigm, especially FreeBSD when McKusick comes out with "The Design and Implementation of the FreeBSD Operating System." A second OS course or a Graduate level one is a better place to have students dive into a real OS, at that point you know the background theoretics of OS work, and you've written a fairly large code base of your own. Then it becomes much easier for students to dive into a real OS and do some research.
For books I'd say the Tanebaum book (already mentioned here) and the 4.4BSD book are very good.
Yes, these systems use Tru64, and Digital's clustering environment including CFS.
Machine interconnect is 200MB/sec system from Quadrix (sp) in the UK. The system is VM aware so you get to do DMA from system to system.
This machine will be about 5 Teraflops. I imagine with the new 64cpu nodes. Single system image. Programming using the MPI specs etc.
-Britt, currently trying to decide if he will take a job in the Compaq Alpha SuperComputer group.
Re:Hmmm... is this a first?
on
The Cat Cam
·
· Score: 1
Nope, you just slashdotted DEAS's weak-ass webserver in the basement. For a while they thought they were under yet-another DoS attack... then they saw the referer logs...
Mac OS X has been delayed precisely because they are trying to perfect the UI for the home user. The future revisions of Mac OS X Server is more likely the one that a power user would use.
MacOS X is not delayed that I have heard (I'm an Apple developer)
Also there is still no official comment on what form of command line interface will exist under OS X. I see it being more like the current Macs, except no crashes, and much faster.
Well, there was the FX!32 package from DEC that let NT/Alphas run NT/i386 binaries by doing a binary conversion ahead when you first ran the program and then storing the translated program for later use. This was maybe 1-2 years ago that i heard about it. They boasted performace of better than PII 266 on their 500MHz 21164 machines. They later moved the tech to Linux/Alpha to let people run Linux/i386 binaries. I remeber running netscape for linux/i386 on my old Alpha station, but it was REALLY slow.
Slashdot Mirror
rpm -qa | xargs rpm -e
I swear there was supposed to be a 'grep gcc | ' in the middle
B
It wasn't an overflow. They ran out of inodes. They had lots of space, but no more inodes, which is why deleting files should fix things up.
The first intergalactice filesystem bug
The problem is that they ran out of inodes. Filesystem freaked out and started to cause panics.
Actually this thing would have melted down and cried in the face of Weta's storage needs, just because it's dense doesn't mean it's fast. You need lots of spindles, and 4 doesn't count. The average FibreChannel disk is good for maybe 200-300 ops per second, so you really want lots of 'em.
They use a mix of NAS and DAS storage, I belive the DAS consists mainly of SGI stuff using XFS and CXFS, while the NAS stuff is all NetApp Filers which can have hundreds of disks
NetApp PR
SGI PR
B
http://www.6speedonline.com/forums/showthread.p
Here is some info from the guy who did the work for
Gates, and wrote the 959 portion of the Show & Display law.
Canepa Design really has had nothing to do with this
B
FibreChannel over copper is quite common.
The usual connector types are HDSC (?) and DB9 (though this only uses 4 pins)
Copper makes a lot of sense for many fibrechannel uses. Connect multiple disk shelves together is the most common, since this only requires 1 foot cables, and copper is much more sturdy than optical, and lower cost for the connecters/interfaces.
Obviously there are limits to what copper can do, the most noticable is the 30M limit.
FibreChannel has has a 2Gb mode for at least a year now with products from many vendors.
LFS (originally by Ousterhout, ported to 4.4BSD by Seltzer) writes everything in a log. Just write as much as possible in one long stripe to the disk (up to a meg in the initial designs.) This means blocks of data move each time they are updated, which means you always write new inodes with each data write which point to the old unchanged blocks, and the new changed blocks.
Obviously once you hit the end of the disk, you have to wrap back around, and write some more, but where?
LFS had a seperate backgroup process that went around and finds all the, now unneeded, old data blocks that have been rewritten somewhere else and cleans them up. This is called the cleaner. Once the cleaner has found more space you get to write there.
The main positive point of the LFS design was very good write performance due to the lack of seeking needed to put little bits of data all over the disk.
The main downside to LFS was the cleaner itself, which was costly to run.
Margo Seltzer and Trevor Blackwell did some more work with the cleaner in this paper that shows that with the right timing you can get the cleaner to run efficiently.
I'm not aware of this work having been implemented (at least not as of 2000 which I stopped working on it on BSDI where Margo had been keeping LFS)
A good description can be found in the original papers, and the Pink 4.4 BSD book by McKusick, Bostic, Karels, and Quaterman.
Britt
The software iscsi initiator for linux can be used with PXE to build a diskless iscsi sysstem. I've been running a diskless linux box for my primary work station for about 2 months.
2x the speed of my old ide drive, and i'm just using 100mbit ethernet.
and my harddrive is backed up now.
Intel has tested this with more than just their target test tool...
Network Appliance released their iSCSI target system which is qualified with this adapter.
Not true. Exchange 2000 will only run on direct attached storage. I'm not sure about SQL server. It will only run on NTFS, CIFS will not work.
The world is designed around people - as they should be.
You sound a lot like Hitler. Take the disabled to camps and gas them. Do you also believe in infanticide for disable babies?
You disgust me.
I think the creepy 50's sterotype police are on their way!
Actually the I/O bandwidth of an SSD is limited by
the fact that many of them have SCSI internally, and even if they have FC back ends you'll only get 35MB throughput, but latency is nice.
a slashdotted server would be probably dealing with a small enough amount of data that it would all be in host buffer cache.
Not True.
Data ONTAP is written in house. The only parts from BSD is some of the network stack, and that has been changed heavily as well.
Harvard also uses this for it's undergrad OS class.
It's certainly not a microkernel though. It's a monolithic kernel running on a MIPS emulator that doesn't have any real device driver system. Granted device drivers aren't really worth teaching in an OS internals class.
Yes, the lack of kernel memory allocation is the single major problem with NachOS. Yes, i need a new kernel data structure, ok 'New...' Some friends of mine will say there are some evil heisenbugs in their code as well, but I don't believe them :). Oh and a couple of really obscure MIPS emulation issues, which I was too lazy to fix.
;)
But yes, NachOS to start, and BSD after that is a very good route in my opinion (some would say OSF1 based on the number of papers that have been published from it as well, though you have to wonder about all those CMU, and MIT people
Ah yes, Harvard's OS course is like this as well. Average assignment is about 50+ hours of coding a week...
Page Fault TWITCH Spawn TWITCH MIPS assembly TWITCH
There's nothing like spending 15+ hour stretches in the lab looking for that one Heisenbug in your VM system...
In my OS class (and at other schools like UC Berkeley, Duke, and Harvard) we used a package called NachOS. It runs on a MIPS emulator, and you write large chunks of the OS yourself. We had to write processes, system calls, filesystems, VM, schedulers, applications for the OS (the shell was just 5% of assignment 2). The final assignment is to write a couple different schedulers or other subsystem, then performance analyize the hell out of it, which was really interesting.
Granted this course has a reputation for being WICKED hard. The whole OS is multi-threaded etc etc, so you have to deal with all the fun race condition issues just like a real OS. Running on a simulator makes life much better for a couple of reasons. 1) crash/rebuild/restart/debug cycle is MUCH FASTER. 2) debugging real kernels w/o having two machines (for serial debugging) is not fun, plus you've got to have the machines for the students, which can be a pain. 3) come on, device drivers aren't the _interesting_ part of the OS, so using a system where thats already done is more useful.
I liked doing this better than what other people here have suggested. I think just writing a device driver is kinda silly. It's a reasonably straight forward project, not really a good thing to do in an OS course, having students working with all the important OS components is much more useful. Starting with Linux is not a very good idea because of the large code base, and from what I've seen it's not really the best code for students to read. I would recommend one of the BSDs if you really want to go with the whole OS paradigm, especially FreeBSD when McKusick comes out with "The Design and Implementation of the FreeBSD Operating System." A second OS course or a Graduate level one is a better place to have students dive into a real OS, at that point you know the background theoretics of OS work, and you've written a fairly large code base of your own. Then it becomes much easier for students to dive into a real OS and do some research.
For books I'd say the Tanebaum book (already mentioned here) and the 4.4BSD book are very good.
Yes, these systems use Tru64, and Digital's clustering environment including CFS.
Machine interconnect is 200MB/sec system from Quadrix (sp) in the UK. The system is VM aware so you get to do DMA from system to system.
This machine will be about 5 Teraflops. I imagine with the new 64cpu nodes. Single system image. Programming using the MPI specs etc.
-Britt, currently trying to decide if he will take a job in the Compaq Alpha SuperComputer group.
Nope, you just slashdotted DEAS's weak-ass webserver in the basement. For a while they thought they were under yet-another DoS attack... then they saw the referer logs...
They don't mind at all....
Lois (manager of deas.harvard.edu), in fact, says "thank you"
Mac OS X has been delayed precisely because they are trying to perfect the UI for the home
user. The future revisions of Mac OS X Server is more likely the one that a power user would
use.
MacOS X is not delayed that I have heard (I'm an Apple developer)
Also there is still no official comment on what form of command line interface will exist under OS X. I see it being more like the current Macs, except no crashes, and much faster.
Well, there was the FX!32 package from DEC that let NT/Alphas run NT/i386 binaries by doing a binary conversion ahead when you first ran the program and then storing the translated program for later use. This was maybe 1-2 years ago that i heard about it. They boasted performace of better than PII 266 on their 500MHz 21164 machines.
They later moved the tech to Linux/Alpha to let people run Linux/i386 binaries. I remeber running netscape for linux/i386 on my old Alpha station, but it was REALLY slow.