Slashdot Mirror
Turing Award Winner On The Future of Storage
weileong writes "Ars Technica highlights an interview at ACM Queue with Jim Gray, a winner of the ACM Turing award *(among other things) by one of the pioneers of RAID (among other things). Many issues touched upon, including: "programmers have to start thinking of the disk as a sequential device rather than a random access device." "So disks are not random access any more?" "That's one of the things that more or less everybody is gravitating toward. The idea of a log-structured file system is much more attractive. There are many other architectural changes that we'll have to consider in disks with huge capacity and limited bandwidth."
Actual interview has MUCH detail, definitely worth reading."
dupe dupe dupe
...does anybody else think this sounds familar?
I must have read an article earlier about this same thing, probably by this same guy. Can anybody confirm that?
Mod me down with all of your hatred and your journey towards the dark side will be complete!
I think we'd all be better off when solid state, non-mechanical disks become commonplace.
Is there any reason other than cost why we can't have 100Gb solid-state drives yet?
Get your own free personal location tracker
This week: You can make a trade-off between latency and throughput!
Next week: Cars that can haul less can be more fuel-effiecent!
The week after: Algorithms that use more memory, but are faster to execute!
If I look at the trends of the last decades, while disk sizes increase exponentially, the actual number of top-level objects I store on my systems increases only linearly, and quite slowly. True, I still store individual documents, but I also store AVIs, ISOs, entire photo albums that take gigabytes each.
It's still random access: I can choose and access an object, even individual photos, without scanning through large amounts of unwanted data.
Ceci n'est pas une signature
I love his commenta about mailing disks to Europe and Asia..
.-D
The biggest problem I have mailing disks is customs. If you mail a disk to Europe or Asia, you have to pay customs, which about doubles the shipping cost and introduces delays.
Thereby adding a corrolary to the old adage "Never underestimate the bandwidth of a vanload of tapes barrelling down the highway"...
"Never underestimate the bottleneck caused by a far-Eastern customs inspector."
A little planning goes a long way...
...does anybody else think this sounds familar?
I must have read an article earlier about this same thing, probably by this same guy. Can anybody confirm that?
Thanks to my well-developed powers of telepathy, I can tell you that you have read a previous article on the topic by the same author. So I'm happy to confirm that for you.
I can also tell you, thanks to my equally well-honed powers of clairvoyance, that this post will soon be modded up as funny.
(Sheesh. And I thought that some recent "Ask Slashdot" questions were dumb.)
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Check out Jim Grey's info page on Microsoft Research He's done research on many diverse and interesting technologies such as distributed computing and sequential I/O performance. There are some nifty sites he has taken part in creating, such as a browsable photo of Earth, and a map of the Universe
they are part of Internet 2, Virtual Business Networks (VBNs), and the Next Generation Internet (NGI). Even so, it takes them a long time to copy a gigabyte. Copy a terabyte? It takes them a very, very long time across the networks they have
Is this really true? Wasn't there a recent Slashdot story where researchers transfered a gigabyte of data, in fourteen seconds or so, on Internet 2 from California to the Netherlands?
I suppose that disk access times will be limiting factor in both ends if you were to read and write the data from/to a disk.
How small a thought it takes to fill a whole life
Frankly the interview was painful every time Dave Patterson said something. How many times does he have to ask questions about the concept of mailing a computer? "We mail computers because transferring over the Internet is too slow for these massive data transfers." "Are they computers?" "Yes." "Do you mail them?" "Yes." "It's like a movie." "Uhh ok." "Is it a whole computer that you mail?" "Yes, it is a computer full of hard drives." "Why don't you just use the Internet?" "Because it is too slow."
...
We have a dozen doing TeraServer work; we have about eight in our lab for video archives, backups, and so on.
..., uhhm..., video archives."
That's a good excuse to use on my wife: "No honey, those are my
Wenn ist das Nunstueck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput.
Does that mean he managed to convince someone he was a computer?
My prof talked about this in my networking class. Apparantly they tweaked the hell out of the data link layer to do this, so it was not a generic data transfer at all.
"Not knowing when the dawn will come, I open every door." - Emily Dickinson
I've seen this a couple times before, but Google seems to come up with nothing useful for it. It doesn't help that every crappy musician who has made a tape sells it out of their crappy van or that so many scientist have the old prussion "van der something" in their names. But perhaps it's crappy musicicans and these van der scientists who really control the highspeed data transfer.
Two quotes from the article (emphasis mine):
Gray, head of Microsoft's Bay Area Research Center, sits down with Queue and tells us (...)
JG: If it is business as usual, then a petabyte store needs 1,000 storage admins. Our chore is to figure out how to waste storage space to save administration.
MS bashers will have a field day on this one...
Wenn ist das Nunstueck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput.
Apart from speculating as to whether this attempt at FUD was the real payload of the article, did it really say anything that most of us haven't already noticed? Whether Flash or fast SCSI, we could do with an intermediate layer of backing store, with faster random access than current IDE HDDs. And we are fast heading for removable IDE drives to be a better and cheaper tape replacement. And the Internet has limited bandwidth. I'm sorry, but you don't need a Turing prize to work any of that out.
Panurge has posted for the last time. Thanks for the positive moderations.
For more info on (very-cool) Log-Structed File Systems, check out Mendel's original paper at:
m l
http://citeseer.nj.nec.com/rosenblum91design.ht
smd4985
One final thing that is even more speculative is what my co-workers at Microsoft are doing. They are replacing the file system with an object store, and using schematized storage to organize information. Gordon Bell calls that project MyLifeBits. It is speculative--a shot at implementing Vannevar Bush's memex [http://www.theatlantic.com/unbound/flashbks/compu ter/bushf.htm]. If they pull it off, it will be a revolution in the way we use storage
I've talked about it before. This guy thinks what Microsoft is doing is revolutionary. Come on all you people, can't you see the problem with today's file systems ? the problem is that the type information is lost!!! we need objects, and we need type information to be stored along those objects!!! This is the only way lots of problems will go away.
This doesn't just affect file storage and virtual memory. It also changes the economics of cache and main memory, and makes deployment of 64-bit CPUs more urgent. It also makes system crashes much less tolerable, because turning the computer off and on doesn't involve long shutdown and boot procedures any more.
So, one could rent a $20K device for $240/year? Those must have been the days...
That can't be right.
I forget what 8 was for.
Chrisd
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
Take this choice quote from the article:
My buddies are being killed by supporting all the Linux variants. It is hard to build a product on top of Linux because every other user compiles his own kernel and there are many different species.
Ain't it sweet? I count five lies:
(1) people being killed by supporting (gasp) operating systems... gosh, horror and violence, not nice at all!
(2) all the Linux "variants", are in fact pretty much one standard, LSB, with several skins
(3) "hard to build a product on top of Linux", rather than, hmmm, Windows? Linux is incredibly easy to build for. I suspect the fact that it's very standard helps.
(4) "every other user compiles his kernel"... maybe at Microsoft. I suspect less than 1 in 20 Linux users ever compiled a kernel.
(5) compiling a kernel means you can't support it... WTF? The kernel is incredibly stable, since most changes are in external modules. And I can't remember a single case where a kernel change broke one of my apps.
(6) (sorry, I was not counting well), "many different species"... well, AFAICS the only difference between the Linux distributions is that they have different packaging methods, different timelines as to their versions, and different UI tools for hardware detection, configuration, etc. Nothing at all that makes life hard.
Look: I just installed Xandros, which is Debian with a nice face. On two different types of machine, and it installed without asking a single question about my hardware except whether the mouse was left or right-handed. Check my journal...
Windows never worked this nicely. Where is the support issue?
In the writing indistry we call this "to condemn with faint praise".
Yeah, Windows kinda works, I mean, it'll run Office without crashing too often, but it's just killing by buddies to have to maintain Win2K, WinXP, and even some older Win98 machines, not to mention we have a whole cupboard simply filled with driver CDs for every PC we have.
Ceci n'est pas une signature
Anyone know what happened to that bloke at keele who
invented a way of cramming 3 Terrabytes on a credit card. Apparently it would have cost about 35 pounds to manufacture. this was a couple of years ago, why hasnt it happened yet?
Surely something like this is the real future of storage ?
Terrabyte on a credit card
Electronic Music Made Using Linux http://soundcloud.com/polyp
"Sneaker net" was when you used your sneakers to transport data?
Oh my. How old I feel when someone has to ask what "sneaker net" was. And someone has to answer...
computerlady - a brand new Slash-daughter - alone, but no longer invisible, in the
Damn, timothy, when it says June on the article it just might be a dupe, ya know? But it's nice to know that the future of disk access hasn't changed since then.
-Looking for a job as a materials chemist or multivariat
This is a *MAJOR* breakthrough! Most Turing Test contestants don't even win, but this one can eloquently discuss topics and give complex answers, rather than just turning back the question, Eliza-style.
Can we download a copy of this "Jim Gray" yet?
What current file systems need is meta data in them. That is that the File system itself stores the MetaData about the file. Think about the Mac File system, with the Meta data contained in the file itself, as the "resource fork". Now imagine a systemized, extensable meta file system, that organized files by what the Meta Data said about them.
Imagine, media files stored in such a way that both random and sequential access was optimized, where the file structure was automagically defragmented and organized behind the scenes.
Imagine a computer that watched what files were used at bootup, and organized them so that the hard drive streamed the bootup data sequentially, straight into memory.
Imagine being able to start PRELOADING applications before you even finish the second of your double clicks on the datafile.
Imagine Database files that were automagically indexed as part of the file system.
Imagine Security and encryption being built into the filesystem beyond today's capabilities, where the security and encryption does not rely upon a master controller or centralized security policies, but rather has the ability to follow the file, seemlessly.
I am sure that I haven't even begun to tap the possibilities.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
With an ever growing collection of digital photos, I've come to the same conclusion as Jim Gray. Hard disks are superior for backups.
I currently have about 100 GB of images and it takes more than 20 4.7 GB DVD-R discs to create a full backup. Although DVD media is still slightly cheaper than new large capacity IDE drives, the added time and hassle factor of burning 20 disks far out weighs any minor costs savings. Moreover a 3.5" drive in a padded anti-static bag takes up less room in the safe deposit box than 20 DVDs (especially if you have the DVDs in protective jewel cases). And if HD-based-backup lets me avoid some future artists tax on burnable media, so much the better.
A Firewire enclosure and a rotating collection of IDE drives is the way to go.
Two wrongs don't make a right, but three lefts do.
Interesting thought popped when i read your post,
there is a current trend towards cramming as much storage into something the size of a 3in Hard drive.
I wonder why they dont make larger harddrives in the physical sense? A hard drive the size of a washing machine using todays technology would store a phenomenal amount of stuff, but whatabout something more reasonable like a hard drive merely twice the physical size of todays. how much more storage could you get just by scaling up the platters? anyone here good at math . Hard drives today must be up to 200-250gb.
Electronic Music Made Using Linux http://soundcloud.com/polyp
There are multiple levels of access within a file system. The sequential versus random decisions they are talking about is at a much lower level than you are thinking. Somewhat simplified:
Now, when software opens a file, it gets a handle to the storage and seeks all over it to get the data it needs and finally write it back. This is particularly true of files that consist of many records. Some software mmaps (memory maps) the file, mapping it into the memory address space and making it appear as a large, slow section of RAM in order to make this easier.
Relatively recently, you see many more programs which open a file, slurp the entire thing into memory, and close the file on disk. When they want to make changes, they open the file again and rewrite it from scratch. You see this more in text editors and word processors. Programming editors will often have some alternate behavior for very large files, although the threshhold for "very large file" is always increasing.
When you do this with record oriented files and or incremental save/autosave, etc, you get into journalling. You write all of the user's changes sequentially to a log file rather than saving the actual file (and re-writing it) repeatedly. This is sometimes what you are seeing when a program has a 'recovery file'. Having only one recovery file or journal for any number of open files means you are consistently writing appends to a single location and avoiding disk seeks.
What the article is getting at is that this sort of behavior will get more and more common, even moving into the FS and OS level. Support for this kind of journalling may move its way into FS handling, for instance. Also, instead of opening individual files, the FS may block transfer a whole directory into RAM at once. We already see this with advanced file systems which store small files directly in the directory inode. We may see the inodes get larger and the definition of 'small file' become steadily larger. When you have GBs of RAM and TB of storage, why not have a 64 MB+ inode?
From this point of view, random seeking within files slowly becomes irrelevent. Rather, the primary operations become streaming and append.
His basic idea is 100% correct, but the reson is all wrong. It *IS* much harder to develop an app Linux the myriad of flavours, not because of the kernel, but because every distro has its own versions of libraries. I work for a company that makes Linux software, and we only support RedHat, and even certain versions of RedHat at that. While our product would probably compile against any number of distros, and even the BSDs, we just don't have the time and manpower required to build, test, debug, package, and maintain 15 different releases for every sub-release or patchlevel we have in the product. With Windows products, at least, (unless you are doing some lower-level stuff) if you build something you can be reasonably assured it will run on Windows 2000, or Windows XP, or Windows 2003. Not the same if you build something with RedHat 9 and try to run it on Debian or Suse, etc. And before you go on about "release a source package", not all companies release everything GPL, and want to keep their IP theirs, since they like to put some money on the table at night. It's definitly not FUD to say it is much more effort to develop and release cross platform binaries in Linux than Windows.
What Gray is talking (mostly) about is what we used to call the "Roadmaster Scenario." When I worked for [a major electronics company], we had a data center in Dallas and a redundant site about 30 miles away in Lewisville. Every Sunday the entire IMS database was archived to mag tape and shipped to the other data center for a second level of redundancy. This begged the question, why not just copy them over the T1 lines (this was 1980) to the other site's tape drives directly? The answer, of course, was that it takes a helluva lot of bandwidth to outrun a Roadmaster full of mag tapes.
"Stop whining!" - Arnold, as Mr. Kimble
> To some extent you can think of Codd's relational algebra as an algebra of punched cards. Every card is a record. Every machine is an operator.
Interesting how the guy literally wrote the book on transactions, yet grossly misrepresents Codd's work, which BTW wasn't simply the relational algebra, but even higher level: the relational model of database management, including the relational calculus.
While the algebra is somewhat procedural, the calculus is set-oriented, and they are fully equivalent. The idea is exactly not looking at records and operators, but describe what you want -- just leave the relational system set the procedures to get that in the most efficient way it can.
Incidentally this has a big impact on all Gray is discussing -- without a fairly simple and powerful data model, so much data is basically a waste. He's thinking too low level, including the object stuff he touts, but we will only find use for so much data the day we get proper relational implementations, and this excludes SQL in general and MySQL in particular.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Certainly 1980s, probably circa 1983 or 1984 at the latest. I came up with the phrase (which may well have been independently coined before me, at the time I was unaware of it) when we were setting up NETNORTH, the Canadian counterpart to BITNET (networks of typically college campus mainframes, not directly part of ARPANET). There was discussion about setting up the HQ at University of Guelph (where I worked at the time - west of Toronto) or Waterloo University.
The highway in question (as in station wagon travelling on) was the Highway (7? it's been a long time) between Waterloo and Guelph (at least part of which I drove every day, since I lived in Waterloo). I don't recall the numbers now, but my calculation of the bandwidth of Hwy 7 was based on a couple of boxes of 2400' reels of 6250 BPI tape (standard IBM mainframe tape size) in a car (or station wagon) travelling at the posted 90 km/h speed limit.
Back in those days, aside from dedicated leased-line networks like BITNET or commercial X.25 packet networks like Tymnet, a 2400 baud dialup modem was considered blazingly fast. (And long distance charges were not cheap, hence the popularity of multi-hop dialup networks using UUCP or like Fidonet.)
-- Alastair
Why don't you send out a mixed source/binary package:
The binary part can be the core of your program and contain all your IP.
The source part can be an interface layer to the rest of the system (aliases for library calls, or equivalent implementations for missing functions, etc...basically a wrapper layer between the system and the program).
During the installation the source part can be compiled and (statically/dynamically) linked to the binary part. The source package doesn't have to be GPL (since, if it linking it to your binary would force the binary to be GPL), but it could still use some other open source license.
That way you can mitigate the disadvantages of a binary distribution without having to use a full source distribution.
Also, if many companies were doing this, it might be a good idea to open source these compatability layers so that every company that makes something for linux isn't duplicating the effort. (though this is kind of what libraries are supposed to do....)
Another alternative is to *trust* your customers:
You could have a full source package, but under a proprietary license (not GPL). Just because the source is available doesn't mean that the customers have full reign over your IP, or even are more likely to pirate it: I have the full "source" for several books, but that doesn't cause me to violate the IP of those authors.
I really doubt that PHB's will go for the full-source approach though, as they tend to be paranoid about such things...which is why I suggested the first thing.......first....