Slashdot Mirror
Database File System
ozy writes "With all the fuss about searching and Spotlight and WinFS, check out the Database File System a completely different interface for your files, implemented in KDE. There is actually a request for developers to join a project to implement this under GNOME and leave how we use the desktop today behind."
...seems to have something more interesting: storage
Of course your right. But knowing that pretty smart people are working on this I don't think your going to see them go ahead with an implementation that's only half the speed of current linux file systems. I'm sure they'll only go ahead with this and integrate it into KDE when the performance is up to snuff. It's simply way too early to say that the benefits out weigh cost until the code is complete.
If you wanna get rich, you know that payback is a bitch
the problem is implementing such things on all unix systems. gnome/kde are not just linux desktops, so it is far easier to implement as part of their platform stack than persuade lots of different kernel development teams to implement it.
While everybody is busy making fun of WinFS, Microsoft is very quietly and successfully letting their customers install SharePoint sites all over the place.
As usual, Xerox came up with the concept years ago (DocuShare). Sigh.
there's no place like ~
No, not in kernel. It should be done as a deamon, like he did.
Nobody is sugesting to use such database FS for entire system. Only for specific data (f.e. user documents) - not entire system (binaries, libraries etc.) where such performance matters. Well in fact it will improve performance since right now applications that need such indexing (best examples are apps for organizing music (like iTunes) or digital pictures colections (like Adobe Photo Album or Google Picasa)) do it themselves which probably is not the fastest way and is not unified across the system. Now for *some* applications such view on files that lets you query for specific files/objects operating on query results rather as directories of files have much benefit. But it is only for organizing data, and in limited scope (as I've said - digital music, photography, probably some other fields). I don't really belive that this would seed up searching for office documents over LAN or smth. - when somebodys documents are in mess DB-FS won't change anything as the documents probably lack metadata, proper naming anyway.
Keeping the traditional file system is only logical as this database sort of file access is in fact a higher level of abstraction.
.....
Considering there are numerious project of such higher level of file access abstraction going on, it does become a secondary choice for the user if they want to use one of these higher abstraction level file access systems.
To remove the traditional file system altogether would be a mistake, as then it could become a system of babel or keywords.... "what was I thinking when I created that keyword and lets not even get into what crazy joe was thining when he came up with his keywords...
But hey, given how MS based developers would create some obscure dll name and place it in some obscure location in order to copy protect
higher level abstractions are useful only to the point that you can, if need be, drop down in abstraction level to get your bearings as to where you are. If you cannot touch physical reality then how do you know you are not floating around aimlessly?
being out of touch with physical reality can evenm be very dangerious and hard to correct.
There are two filesystems I know of, off the top of my head, which support versioned files. The first is VMS and the second is ISO9660. I suspect the VMS file versioning probably came from TOPS so you could be right there.
Yes, ISO9660 really does support versioning. You can create files and add a version number using the ; seperator E.g. FOO.TXT;1 and FOO.TXT;2 etc. A compliant ISO9660 can either show you all of the available versions if your OS can cope with it or just chooses the latest version (E.g. for systems such as MS-DOS). I'm not totally certain how versions are handled if you use RockRidge or Joilet extensions; the original ISO Level 1 names are still there but you'll only see the extended filename if you mount a RockRidge disc with a RockRidge ISO9660 driver, so you probably won't see the different versions. It's been a while since I fiddled with an ISO9660 driver to be honest.
For those of you that have not yet looked at the Mac OS X (Tiger) preview and WWDC web cast, the new spotlight technology built into the next version of Mac OS X looks very much like a fully integrated database file system. And it's incredibly fast. Go check it out!. Note: QuickTime required. Mplayer may work for us Linux heads but I haven't tried it.
-- DuckWing
Close. That's a VMS feature.
This next song is very sad. Please clap along. -- Robin Zander
Yeah right. And whole world will use this daemon.
/mnt/volume/Personal/$ftype
Problem with this logic is that not everybody is gonna use DBFS. For example: Some people would like to use Reiser4.
Proper thing would be dummy kernel (or some higher VFS, but making whole thing independant of wheter graphic mode is present or not) API for this kind of file access. If accessed FS is not DB related then it should convert standard functions (implementing some Metadata index on basic FS). If accessed system is Database FS then it should go trough it's native layer.
Who says that
MOVIES="*.avi *.mpg *.qt"
for ftype in $MOVIES; do
ls
aka.
select from fs where (path = '/mnt/volume/Personal/*') and ((path = '*.avi') or (path = '*.mpg') or (path = '*.qt'))
is different than
select from fs where ((type='movie') and (location='Personal'))
Second option could pose other options. Like searching by actors and directors, MP3 info, Office tags etc. But all open and save routines could be done trough and with Metadata. While Metadata and data would be connected.
Let's say I copy MP3 files from CD. CD is not DBFS. All my tags go down the drain. Hope you don't expect I will copy all files trough this daemon or in graphic mode at all. Just as on plain system as on DBFS.
Off course, it would help if VFS layer could detect MIME and act accordingly. Example: Old ISO9660 burned CD (or even better ssh mounted drive) with MP3. I copy these files to my computer remotely from terminal console on some other computer, computer being copied to, resolves ID3 and updates Metadata from ID3 tag index on fly. Without having some cron job.
Same thing goes for my Office files. All files have it's creator and it's description. Why wouldn't go in Metadata index when file is received and saved from e-mail. If this problem is not solved before implementation then all you can expect are holes in your Metadata with a lot of non-indexed data.
Well, that example is nothing new. Reiser4 already does that with plugins. The question here is:
Will everybody use Reiser4? NO
Will everybody write metadata plugin for Reiser4? NO
Will Gnome or KDE support Reiser4 directly? NO
Would this have better chance when Universal file access would be defined independent from FS and independant from Graphic mode? YES
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
You don't need to do anything to Gnome. There are plenty of existing Linux desktop environments that sound like they'd work for you. Take a look at xfce. If you want it even more stripped down, then try BlackBox, IceWM or WindowMaker. Most distros include all of the above.
no, there are many kernel projects, you missed the point, there is not just linux, there is all the bsds, solaris, irix etc. etc.
Search for: Documents
Modified since: last backup
I don't know about the other implementations but Searchlight and WinFS are implemented atop the existing filesystem. (The FS in WinFS supposedly stands for "Future Storage" and not "File System") Sort of like how Google is implemented "on top" of the regular hypertext-linked internet.
This did mean that you had to use the right tools to get into the files or you had to cope with the changes in programs that worked on them.
VMS also had file revision numbers on files as a couple of posters have noted.
Both of these were nice in some ways, but relatively difficult to deal with in other ways. By comparison unix is straight-jacketed but easy to use.
Before inventing something you should check if no one did this earlier. Because there you have GNOME Storage. Don't be fooled by screenshots there. Storage isn't only cool search facility with native language parser ("computer, find me all porn I've downloaded yesterday" anyone?).
Storage is, suprisingly, method to store files decomposed to contents. The great searching ability is a side effect.
Imagine collaborating in of group of people over one document. Every one got some paragraphs to edit. With Storage, everyone can edit this document in the same time, seeing other's changes as letters are typed. Store version history and you have revision control. Throw in network transparency (you go to other department, connect laptop and automagically you can work on those department files) with OpenTalk (Zeroconf/Rendezvous) and you got best idea since hierarhical directories.
Be sure to read whitepaper about Storage available on mentioned site. Also check for Storage related entries in Seth's blog (Seth is one architect of GNOME Storage). Now if only KDE people work on compatibility with Storage, freenix desktop would rule the world.
BTW, KDE, don't miss chance of integration! KDE is planning to introduce google-like search in desktop. Don't reinvent wheel! Beagle is here, working. Just integrate Beagle with KDE desktop and we are set.
:wq