Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Database File System

Hemos posted about 10 years ago | from the no-matching-records dept.

KDE 296

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."

cancel ×


Sorry! There are no comments related to the filter you selected.

FIRST FISH! (-1, Offtopic)

Anonymous Coward | about 10 years ago | (#10168843)


Re:FIRST FISH! (-1, Offtopic)

Anonymous Coward | about 10 years ago | (#10169085)

"I'M A FISH!" .....and after you're gutted and skinned, you'll be broiled and served with drawn butter and some fava beans and a nice chianti.....

gnome people... (3, Informative)

alphan (774661) | about 10 years ago | (#10168861)

...seems to have something more interesting: storage []

Re:gnome people... (3, Informative)

Jellybob (597204) | about 10 years ago | (#10168879)

Storage has been more or less dead as far as I can see for a while now, however Beagle [] is showing good progress on the same front, having been demoed at conferences recently.

Re:gnome people... (1, Informative)

Anonymous Coward | about 10 years ago | (#10169082)

Well if you think 3 weeks is a long time...
One of storage creator Seth Nickell and Marco Pesenti Gritti of epiphany fame seems to still be working on it.

Re:gnome people... (-1, Flamebait)

Anonymous Coward | about 10 years ago | (#10168992)

Hey, no kidding. Let's just add this one to the growing list of KDE hyped-up non-stories that the slashdot editors have posted recently.

You know, it will be an interesting day when the KDE project starts producing instead of just writing press releases and making outrageous claims.

Finally (-1, Troll)

keeleysam (792221) | about 10 years ago | (#10168863)

People want more stuff in gnome not the bloated KDE

Why bother.... (-1, Flamebait)

Anonymous Coward | about 10 years ago | (#10168868)

Why bother porting it to Gnome. The worst window manager ever. The choice of KDE was a smart move on Onne Gorter's part. Gnome is an absolute piece of crap, whereas KDE is a window manager that could be use in the enterprise today.

Re:Why bother.... (1, Funny)

Anonymous Coward | about 10 years ago | (#10169001)

neither gnome nor kde are window managers, and I doubt berman would allow either to appear on enterprise today or tommorow.

Re:Why bother.... (1)

justsomebody (525308) | about 10 years ago | (#10169007)

What a stupid thinking. Both things: Making it for KDE and porting it to Gnome.

In reality DBFS should only provide higher API besides standard one. And if desktop or application supports this API here's all of the functionality. If not plain FS access is all you get. In Gnome case gnome-vfs should detect and use DBFS, and in KDE probably the equivalent is KIOSlave.

Kernel should set some standard API for filesystems like DBFS and Reiser4 if not for other reason then to set starting access point for filesystems like these.

Backups, and being organized in a general way? (5, Interesting)

manavendra (688020) | about 10 years ago | (#10168870)

...I can kind of see this would make it easy to search and locate documents. What about backups though? How would a user be able to group (manually) related files together, so that the whole bunch can be backed up later, without having to search for all seeminly related (or unrelated) keywords to trace all hitherto-unrelated documents?

Secondly, with this mass of files being spread over several disks, surely, this is in a way forcing the user to "search" for everything. Or isnt it? Will the underlying FS layer still be accessible in the general way that it is?

Re:Backups, and being organized in a general way? (3, Funny)

manavendra (688020) | about 10 years ago | (#10168893)

Oh, and forgot to add that I wouldn't be happy if my disk begins to churn away as the "Crawler" updates its indexes, say, while I'm playing doom! Can't afford to have any other spooky, disk grinding noises, while squinting my way through those dark corridors..

Re:Backups, and being organized in a general way? (4, Funny)

manavendra (688020) | about 10 years ago | (#10169009)

Well, you may find it funny, I've already messed up two pair of trousers - once when my phone rang and second when my friend put his hand on my shoulder to get my attention...

Re:Backups, and being organized in a general way? (5, Funny)

Aeiri (713218) | about 10 years ago | (#10169068)

You should have posted that as Anonymous Coward...

Re:Backups, and being organized in a general way? (2, Interesting)

carnivore302 (708545) | about 10 years ago | (#10168925)

Will the underlying FS layer still be accessible in the general way that it is?
Sure, because the dbfs is implemented in userland. All applications will work as before, including ls.

I wonder if this could be made into a plugin for reiserfs 4.


Performance? (2, Interesting)

saden1 (581102) | about 10 years ago | (#10168871)

Isn't this thing with DB's getting a little excessive? You're adding another layer and step to storing data which will in all likely hinder performance. I'm not sure the benefit out weight the cost.

Re:Performance? (5, Insightful)

Anonymous Coward | about 10 years ago | (#10168970)

Depends on what you are using your computer for of course.

You can say the same thing for a GUI, and its correct for certain applications of computers, but wrong in others.

Re:Performance? (2, Informative)

bogie (31020) | about 10 years ago | (#10168975)

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.

Re:Performance? (0)

Anonymous Coward | about 10 years ago | (#10169030)

That'll take forever, code is never complete ;)

Re:Performance? (4, Insightful)

psavo (162634) | about 10 years ago | (#10168982)

Isn't this thing with DB's getting a little excessive? You're adding another layer and step to storing data which will in all likely hinder performance. I'm not sure the benefit out weight the cost.

Well, if it's only a name-translation thingy, then it shouldn't affect performance of file reading (when operating on sufficiently big files), only file opening/stat:ing.

Re:Performance? (0)

Anonymous Coward | about 10 years ago | (#10169134)

ls -l / > /dev/next_life

Re:Performance? (4, Informative)

kosmosik (654958) | about 10 years ago | (#10169089)

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.

What About Code Bloat? (3, Interesting)

reporter (666905) | about 10 years ago | (#10169095)

These days, operating systems like both Linux and Windows XP have too many bells and whistles that I simply do not need. Unfortunately, these bells and whistles drastically increase the amount of space that I need on my hard drive.

Adding a database layer to Gnome sounds like using another 300 megabytes of storage on my hard drive. I simply do not need the database.

If the FSF/GNU folks really want to do something revolutionary, they should fork Linux+Gnome into 2 distinct paths: minimalist and maximalist. The maximalist is what we have now. The minimalist is a minimally featured Linus+Gnome distribution. It is the bare minimum in functionality that we need to have a decent operating system and desktop.

Into this minimalist installation, I will then add the applications (e.g. MatLab) that I use daily.

Re:What About Code Bloat? (0)

Anonymous Coward | about 10 years ago | (#10169201)

There are so many distros that exactly match what you're describing. How small do you want to go? DSL is quite a bit smaller than even the Win98 install. Works fine as a hard drive install. I have one right here it has Blender, Gimp, OpenOffice, Firefox, NX Client, XMMS, Xterms and almost nothing else. Okay, a few Xmame games but I wouldn't call that bloated and yet it has some very high power apps and it is fast even on an old PC.

Re:Performance? (0)

Anonymous Coward | about 10 years ago | (#10169116)

Not only that but someone, somewhere has to manually enter all the meta-data which may consume more time than a search on a traditional file system. I have all the file search tools I need, directly from the shell and metadata is only created once per directory, then becoming a part of the path eg: /home/user/images/raster/logos/companylogo.png

Who cares if a database cross-indexes, a shell script can do that and knowing exactly where a file is will always be faster than searching for a keyword. It may work for google but I don't need or want this, I can't imagine any use for it on the company network either. Blaghhhhhhhh.

Re:Performance? (4, Insightful)

BenjyD (316700) | about 10 years ago | (#10169126)

Why not just run in console mode? All this GUI stuff is just getting in the way of absolute performance.

If it adds 0.5 seconds to every time you save a file, but saves you 20 seconds of filesystem navigating every time you open the file, that's a worthwhile tradeoff. Add to that the fact that copmuters don't get tired or bored, while humans do, and it makes even more sense to shift as much of the burden of working onto the computer as is practical.

Re:Performance? (0)

Anonymous Coward | about 10 years ago | (#10169174)

I do run 'in console mode', you insensitive clod!

It takes longer to navigate using a GUI than by using tab-completion, sorry.

Re:Performance? (4, Insightful)

jgardn (539054) | about 10 years ago | (#10169159)

Not necessarily. Consider the performance of finding a document you wrote two years ago. How long does it take you to walk through the directory hierarchy browsing file names? How fast is the file search tool? Wouldn't it be faster if you could say "Show me the documents I wrote two years ago" and the refine the search or browse the results?

Storing data in a relational database is natural because it is more like the way we store data in our minds than the hierchical structures of traditional file systems.

Also, we allow a complete abstraction of the underlying database in relational systems. The database can store the data however it sees fit, and can arrange the data on disk without the users noticing a change.

I look forward to experimenting with a relational filesystem. I think it would be a wonderful thing to try out and see if it actually has the advantages I outlined above. I'd also like to see the actual disadvantages.

Re:Performance? (-1)

Anonymous Coward | about 10 years ago | (#10169233)

ls /home/user/Documents/General/2002/
You didn't say what month!

Re:Performance? (1)

Glock27 (446276) | about 10 years ago | (#10169280)

Isn't this thing with DB's getting a little excessive? You're adding another layer and step to storing data which will in all likely hinder performance. I'm not sure the benefit out weight the cost.

[sarcasm]Yeah, you sure wouldn't want to gratuitously use the 99.5% idle time your desktop computer is currently wasting.[/sarcasm]

Actually, my sarcastic response isn't even right..this will only affect performance when you're searching for a file, or saving one. How much time do you really spend doing that? Further, how much time will you save because you're able to find things efficiently? Nothing wrong with using the CPU to simplify life for the user...if the user so desires of course.

Looks like an interesting project...

"Implementing in GNOME" (5, Insightful)

kosmosik (654958) | about 10 years ago | (#10168873)

Such thing should be implemented at kernel level to be transparent for *any* aplication. Without this it will just lead to a mess (like 4 different implementations) and some apps working with it and most not. As f.e. you can browse SMB network with Nautilus but when you actually try to open a file (from SMB via Nautilus) in you will get a info that viewer does not support this method... It must be a standard system routine not another level between system and GUI.

Re:"Implementing in GNOME" (1, Informative)

Anonymous Coward | about 10 years ago | (#10168979)

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.

Re:"Implementing in GNOME" (0)

Anonymous Coward | about 10 years ago | (#10169215)

No, the real problem is that there's a kernel project and there's DE projects (KDE/Gnome), but nobody's in charge of the stuff in-between.

Therefore if someone has a good idea, the only practical way to get it into the operating environment is either through the kernel or through KDE/Gnome. (which is why the kernel is loaded with filesystems that could be in user-space, and the DEs have way too much low-level functionality)

Re:"Implementing in GNOME" (2, Insightful)

slimyrubber (791109) | about 10 years ago | (#10169008)

Actually database storage should be implemented in the filesystem rather then kernel or window/desktop managers. That would make much more sense and theoratically, it will be faster.

Just my uneducated opinion.

edit (1)

slimyrubber (791109) | about 10 years ago | (#10169040)

What I ment is.. DFS interface should come as filesystem tool (xfsprogs, e2fsprogs, reiser4progs etc) rather then depending on one desktop or window manager.

Re:"Implementing in GNOME" (1)

eludias (124857) | about 10 years ago | (#10169017)

Just because distributions/developers cannot standardize upon one library for all their filesystems needs does not mean it has to be implemented in the kernel. Having kernel support for synchronising an index with the filesystem it indexes makes sense, but not to have a complete implementation in the kernel.

The same reasoning would put Gnome or KDE into the kernel so this won't lead 'to a mess' and different applications working differently.

Re:"Implementing in GNOME" (2, Informative)

Henk Poley (308046) | about 10 years ago | (#10169024)

No, not in kernel. It should be done as a deamon, like he did.

Re:"Implementing in GNOME" (0)

Anonymous Coward | about 10 years ago | (#10169088)

please, mod parent up. In the article is a description of the system which explains that the userinterface and the functional layer are seperated (and not dependent on the windowing/widget system).

GNOME has Beagle (Re:"Implementing in GNOME") (1)

otisg (92803) | about 10 years ago | (#10169051)

Read about Beagle here [] . I posted about this on Slashdot a few days ago.

Apple (-1, Redundant)

CompSurfer (759218) | about 10 years ago | (#10168876)

Sounds similar to Spotlight [] , the file searching system in OSX Tiger.

Re:Apple (-1, Flamebait)

Anonymous Coward | about 10 years ago | (#10168995)

Sounds similar to Spotlight, the file searching system in OSX Tiger.

As linked to in the friggin' article? Look, karma has no value, so there's no point going fishing for it. Maybe you just want to contribute to the discussion, in which case you should really try to write something worth reading, which the above isn't. Perhaps you could say why the two things are similar, and how they're different, and maybe toss out a quick useability assessment. But what you've done instead is written the equivalent of "Heart bypass? Sounds similar to to an appendectomy." Whatever.

Find what I say interesting? Perhaps you could befriend me

Oh, fuck off.

File system in KDE... (1, Insightful)

JakeThompson1 (808024) | about 10 years ago | (#10168878)

So now, you will lose access to your file system if you use a simple window manager instead of KDE?

Great idea.

RTFA (1)

1qa2ws3ed (662567) | about 10 years ago | (#10168904)

"The DBFS does not actually store files, it holds references to files on the underlying hierarchy based file system. The GUI part is implemented in KDE where it replaces all hierarchy based file accesses. This gives an impression that there is no hierarchy, but to applications nothing has changed, the open-file and save-file dialogs have the same APIs."

Re:RTFA (1)

JakeThompson1 (808024) | about 10 years ago | (#10168922)

So... With KDE application, user gets pretty dialog with nice database-organized file system.

With GNOME (until this is implemented), or Motif application... they get the "hierarchy"...

And people thought the GTK Open/Save dialogs were bad before...

Re:File system in KDE... (2, Interesting)

mn3m05yn3 (772460) | about 10 years ago | (#10168905)

Doesn't seem to be true. Article indicates the DBFS will run on top of other filesystems. if you don't use KDE, you don't use DBFS... ext2/3 etc is still there. The real question is whether you can use KDE without using DBFS...

stubborn (3, Insightful)

mn3m05yn3 (772460) | about 10 years ago | (#10168882)

Article doesn't address whether or not we can turn DBFS off and use the more traditional hierarchical method of file placement. Will we be dragged into this kicking and screaming?

Re:stubborn (1)

LegionX (691099) | about 10 years ago | (#10169046)

"This gives an impression that there is no hierarchy, but to applications nothing has changed, the open-file and save-file dialogs have the same APIs."

it does..

Your filesystem is still there.. hidden.. waiting..

Re:stubborn (1)

I confirm I'm not a (720413) | about 10 years ago | (#10169062)

Article doesn't address whether or not we can turn DBFS off and use the more traditional hierarchical method of file placement.

I would imagine the article author thought it was a given: we currently have choices of various file-systems, with no one FS requiring it be used to the exclusion of all others. I'd be highly surprised if DBFS was any different: people who want to use it will use it, and people who want to use Reiser4 will use that, and people who want to ext2 will use that.

Re:stubborn (2, Insightful)

donkeyboy (191279) | about 10 years ago | (#10169148)

Most of these DB File System implementations overlay the existing file system. The standard file access methods are still there. The DB functionality is implemented as extensions.

The DB tables are then implemented as special files that coexist nicely with the existing directory files.

Keep in mind that if a "new" file system breaks heirarchial file access is also breaks every app in existance.

Version control would be nice as well (5, Interesting)

zero-one (79216) | about 10 years ago | (#10168883)

I have always thought that version control (file histories, branching and atomic changes) would be nice to have at the file system level. Instead of storing myessay-firstdraft.doc, myessay-seconddraft.doc, myessay-final.doc, the file system should do the work. Then if I want to make a bunch of changes (perhaps I want to try a new page layout), I should be able to commit them as one atomic change (or throw them all away if I change my mind). Then, when I want to make a set of documents with US spelling, I should be able to branch the whole lot (using no disk space) and make the small changes from UK spelling while still being able to integrate other changes I have made.

Re:Version control would be nice as well (4, Interesting)

ultrabot (200914) | about 10 years ago | (#10168939)

I have always thought that version control (file histories, branching and atomic changes) would be nice to have at the file system level.

Sounds like a job for an SVN plugin for Reiser4 file system. Anyone doing one already?

Re:Version control would be nice as well (1)

trynis (208765) | about 10 years ago | (#10169039)

I've been told the file system for Tops-20 had built-in version control. I tried to google for a reference, but failed. Maybe someone could enlighten me?

Re:Version control would be nice as well (0)

Anonymous Coward | about 10 years ago | (#10169203)

VMS had something similar: file;1, file;2, file;3, &c...

Re:Version control would be nice as well (3, Informative)

Anonymous Coward | about 10 years ago | (#10169207)

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.

Re:Version control would be nice as well (1, Interesting)

Anonymous Coward | about 10 years ago | (#10169193)

There is some non-free software which does this kind of thing, such as Tower [] Trim Context. We've been implementing this at my office. Users are often less than enthusiastic - because it changes the familiar Windows world, and breaks things like links in Office documents which depend on HFS storage...

Interesting concept (1)

BCW2 (168187) | about 10 years ago | (#10168886)

I like the looks of this and the way it can search the file system. Nice job! This would be a great way to keep track of multiple projects. Blows away the Winfs idea, I will try it out.

Re:Interesting concept (1)

EddWo (180780) | about 10 years ago | (#10169161)

How does it blow away the WinFS idea? It basically is the WinFS idea. It stores metadata and file relationships in a database with a reference to the file location in the traditional hierachy.

WinFS does all that and more with automatic metadata promotion/demotion, synchronisation, and queries generated by virtual paths for legacy applications.

Re:Interesting concept (0)

Anonymous Coward | about 10 years ago | (#10169282)

Well let me be the first to say that if this is even remotely similar to the big WinFS hoopla then MS is in really bad shape because all I can say is --yawn.
I really don't get this. I don't really care about bloat. But I mean if it's just about finding files it's not that big of a deal. By now I think most people have figured out ways to find their files using existing tools such as mnemonic devices and using directories in a reasonable way such as folders with dates and such. I mean if you've ever spent time looking for files that probably taught you to be more responsible about where you put them.
I don't really buy this scenrio about a person with a big media project losing their files and finding them with this kind of tool. I do big media projects with tons of audio, video, text, code all woven together and if I didn't make my directory structures carefully I would never be able to finish a job. So, a media pro probably doesn't really need a tool like this as they already do things such as backups that force them to be somewhat cognizant of what goes where.
That gives us the amateurs. But I think something like this just makes them lazy which is a bad idea. The key idea for this group is that amateur computer users need to understand what a path is and what a tree looks like and how it can help them organize their files. This is basic stuff that people should understand. Hiding it isn't really doing anybody a favor. Anyway, a path in a filesystem is not too different from a URL so even kids are exposed to the idea from very early.
So if pros don't need it and amateurs shouldn't depend on it, its doesn't seem to be such a big deal. I mean if people want it that's cool. But I don't see this as a make or break item.

Disadvantages (4, Insightful)

BHearsum (325814) | about 10 years ago | (#10168891)

How much permforance overhead will this cause? The 'Desktop Environments' already eat a lot of RAM and CPU.
How much disk space will you lose over this? All the metadata has to be stored somewhere, and just glancing over the link I read something about a versioning system, which will definently take up quite a bit of space. Will a 20gb hard drive become 15gb with DBFS?

Re:Disadvantages (1)

MemoryDragon (544441) | about 10 years ago | (#10169115)

Performance penalties, hard to tell, I assume for plain searches, the whole thing is faster. Read access might be the same because it goes plainly to file system level. Write access probably add a few miliseonds per file, to have the index updated, probably not if you have atomic commits on filesystem level and can do the indexing multithreaded. (reiser4 comes instantly to my mind)

Re:Disadvantages (4, Insightful)

aodl (451686) | about 10 years ago | (#10169179)

While performance is something that should always be kept in mind, we are a long way away from the days of the original Macintosh where a desk accessory had to weigh in at 600 bytes [] in order to make the cut and fit into both memory and on a floppy disk. As current desktop machines outperform the high end servers of a few years ago, it would be nice to put a lot of that muscle to use in improving the user experience. I'm not excusing bloated and slow code here, but we don't really need to be counting bytes.

In any case, database based operating systems have been around for decades, from OS/400 to the BeOS. Many BeOS users claimed it was hands down faster than any other shipping OS at the time, and it featured a journaling, database-styled file system. One of the primary developers of that file system is now working at Apple on Mac OS X 10.4's spotlight functionality.

The thing is - as our desktop storage continues to grow at the pace that it does, and as we curiously find ways to fill it up, new ways of looking at and finding the information we store are going to be needed.

DBFS, Gnome Storage, Apple's Spotlight, and WinFS, all take different routes to get there. It's worth looking at all and what they offer and where they differ. WinFS, is a new storage layer that combines file system resources with more structured data in a Relational/XML hybrid system, with the aim (from what I gather) of turning the file system into a global "soup" of data. That sort of soup can be seen in office suites or PDA style applications, and in older Operating Systems like the Newton OS, where everything is a shared and available resource that is stored and available through common structures. Spotlight, on the other hand, combines file system searches and indexes (think 'locate') with full content indexes and a metadata index, which uses 'importers' to parse out other file formats. Spotlight is not a new file system, but an indexing system that acts on files in the file system. From what I remember of Gnome Storage, it is similar, using the VFS layer and Postgres triggers and callbacks, along with plug-ins, to parse and extract relevant metadata and contents out of files. DBFS looks to be like WinFS in that it purely wants to be a new kind of information store. I don't know which style will win out. My theory is that technologies like Spotlight will eventually evolve into a new kind of storage system, while remaining familiar and file based for todays users and developers. But this is an idea whose time has more than come. It's something that's been promised for the desktop for at least a decade, and has been shown to work, albeit in targeted OS's (the Newton) or ones that never achieved mass market penetration (BeOS).

So I think that performance concerns aren't that big of a concern, so long as (like all development) there are good people working on the solution.

i don't have time to reinvent the wheel today (1, Flamebait)

non (130182) | about 10 years ago | (#10168901)

why don't the nice KDE people and the nice Gnome people work on developing a library that sits on top of this [] and then we can stop all the stupid name calling and use the right tool for the right job

Re:i don't have time to reinvent the wheel today (1)

LousyPhreak (550591) | about 10 years ago | (#10169075)

maybe because not everyone wants to use reiser4?

Re:i don't have time to reinvent the wheel today (0, Flamebait)

JohnFluxx (413620) | about 10 years ago | (#10169114)

What an arrogant dick you are.

blah blah blah (2, Insightful)

Anonymous Coward | about 10 years ago | (#10169163)

Sorry, but I have to say it, you are an idiot!
Did you even care to RTFA?
This has nothing to do with the gnome or kde devs. Some developer invested his time to come up with something he thought was useful and all you can do is complain?

And if you look at the project, it is something completley different then a plugin for the admittedly great ReiserFS4 and it is here and usable right now.

So friggin stop your stupid whinig.

And to the mods who modded parent interesting ...

Btw., why don't you whine to the Reiser people that they should stop developing now? It would be as justified as your whining aboutt this project.

Reiserfs, storage and why do you want this? (4, Interesting)

ACK!! (10229) | about 10 years ago | (#10168921)

Perhaps I am more organized than most but I already categorize my files and such in the hierachal file structure.

Isn't Rieserfs planning to do this on the kernel level?

Where does that leave other fs choices and storage and other idea dbfs?

I see more and more people saying look what neat things you can do with these tools.

But really why do you personally want something like this?

Curious to see the response is all.

Re:Reiserfs, storage and why do you want this? (3, Interesting)

BenjyD (316700) | about 10 years ago | (#10169065)

The problems with the hierachical system are:

- maintenance overhead on part of the user to create hierachy and maintain it. Every time you save a file you have to think "where do I put this?"
- Finding files can be hard. Is that letter about the planning application in Documents/Letters or Documents/Planning App?
- keeping files in two or more places at once is hard (as in the previous example). You can use softlinks, but that's hardly ideal and doesn't survive moving things around.

Basically, the current file system imposes a significant overhead. Most power users have restructured the way they work and use a computer in order to minimise that overhead without really noticing. It's just become one of those things you have to do, like remembering to save documents.

Why not shift the burden of organising the files onto the enormously powerful computer, rather than take up valuable human mental resources.

Re:Reiserfs, storage and why do you want this? (2, Funny)

Aeiri (713218) | about 10 years ago | (#10169127)

- Finding files can be hard. Is that letter about the planning application in Documents/Letters or Documents/Planning App?

find ~/Documents | grep "planning application"

You've just taken a giant step into learning how to search for files in UNIX! In my next tutorial, I'll teach you the power of the "locate" command.

Sweet - now do it with DOC, PDF and JPG files (1)

mgkimsal2 (200677) | about 10 years ago | (#10169191)

"grep" - why didn't anyone else on the planet think of that one? That's fantastic. Now I just HOPE to goodness I've always managed to always save everything under ~/Documents, never anywhere else, and then make sure I'm only searching for ASCII data inside any files. I'm all set! Thanks. You've made it much easier for me to find all my pictures and audio files related to various topics.

Re:Sweet - now do it with DOC, PDF and JPG files (1)

chill (34294) | about 10 years ago | (#10169232)

Meta data. All three formats you mentioned support embedded meta data.

And YES, I would expect people to actually remember to enter proper meta data for their documents. If not, then they don't get the benefits of this type of system.

Re:Sweet - now do it with DOC, PDF and JPG files (1)

mgkimsal2 (200677) | about 10 years ago | (#10169263)

I'm not sure grep would always find the metadata in those - maybe it would. As another person pointed out, SXW files wouldn't easily be searchable (haven't looked at metadata for those). Assume that though all those file formats *do* have metadata available, wouldn't having a standard way to search and filter all those various metadata formats in one file dialog be a good thing? If this (or another) project would do that, I'd be all for it. And for those file formats that don't support metadata, this system would allow for the creation of metadata for those files. :)

Re:Reiserfs, storage and why do you want this? (1)

BenjyD (316700) | about 10 years ago | (#10169211)

And if I called the file planning_app.sxw? plan_app.sxw? "letter to council.sxw"? "Planning Application" wouldn't even match your example. Yes, a bunch of regexs would probably find it, but that's a fairly involved process just to find a file I only need for a few seconds to look up a name or something.

The point is, for most people the overhead of naming and organising files has become subconcious, and we have a bunch of tools to sort-of work around it. That doesn't mean an attempt to create a different system to remove the overhead completely isn't worthwhile.

Re:Reiserfs, storage and why do you want this? (2, Insightful)

TheRaven64 (641858) | about 10 years ago | (#10169254)

I find that a spacial interface to a hierarchical storage layout makes it very easy when I want to find my files. This kind of thing is more useful when trying to find files you didn't create / save.

software? (2, Interesting)

Alosja (787167) | about 10 years ago | (#10168944)

might sligtly offtopic, but is there any open source software for windows that could do the same thing? I produce a lot of notes, and i want to be able to categorize my files.

Comments by the Author (5, Interesting)

data1 (23016) | about 10 years ago | (#10168945)

The author is asking for help to move the project to Gnome.

Quote:There is of-course the hard choice of platform. I choose KDE? because I am familiar with QT a bit, and because it is inherently object-oriented, being C++ and all. But in my mind GNOME? is much closer to how I would like a desktop system to function. So I would like to go for the GNOME option. I leave KDE developers to do what they want with this, and I am offering them support. But I would like to focus my efforts on GNOME and implementing the above in GNOME.

Any volunteers?
In the first place we will need developers. Would you like to join, send me an email ( with DBFS and JOIN somewhere in the subject. If you are not a developer, but still would like to help, please revisit this page in a few weeks. There will probably be a community website by then somewhere.

What happen to the OODB? (2, Insightful)

jeanicinq (535767) | about 10 years ago | (#10168967)

The database file system originated from the ideas of an object-orientated database. Keywords and references are all part of the orientation objects of the database to index to files or other objects. It does away with the traditional hierarchal view, being rooted at some place. The OODB does not need to be rooted as it is more like a web. The DBFS seems to try to implement part of the concept of the OODB. Good. There are many more features an OODBFS can offer: dynamic organization, classification, and mutliple "skeletal" views to name a few. I hope that this DBFS will give a taste of what an OODBFS offers.

Sigh, Andrew Morton seemed to be right... (5, Interesting)

greppling (601175) | about 10 years ago | (#10169004)

...when he said on LKML, slightly paraphrased: "The only reason I see to put filesystem semantic enhancements into the kernel, is that it would be socially hard to get people to agree an a single userspace library."

(In the course of the heated discussion about Reiser4.)

SharePoint anyone? (2, Informative)

Petronius (515525) | about 10 years ago | (#10169020)

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.

Re:SharePoint anyone? (2, Interesting)

Anonymous Coward | about 10 years ago | (#10169248)

It feels like sharing files in the manner that SharePoint does is an afterthought. First, they built a web portal, then they decided to add that feature in, along with a few ActiveX controls. More important to SharePoint was the web portal component. Where I work, everyone has a SharePoint site for a default webpage. This allows for simple announcements and memos without choking down the email system. It's also fairly unobtrusive, which allows users to read said memos if/when they like, rather than forcing it into their inbox where it would inevitably get deleted.

This is not a file system (4, Insightful)

MobyDisk (75490) | about 10 years ago | (#10169029)

Maybe we could call it a "filing" system since it indexes files that are on another file system. Really, a file system IS a database, not an add-on that indexes files. Still, perhaps this is a better approach than trying to redo all the file-system internals. Although to be truly useful, this needs to be an API that is GUI-independent, with GUI-bindings as needed.

Stop letting goof ideas (2, Interesting)

DarkOx (621550) | about 10 years ago | (#10169033)

Stop letting good ideas be victimized by the M$ marketing FUD machine. Someone said "database filesystem" That was a good idea. M$ can along and said gee lets steal that idea. Hey there is no existing implementation to copy how do we do it. The answer is they did not do it. They put a database to keep rather mundane information on top of NTFS(a real filesystem) and called it WINFS(NTFS and a almost completely unrealated database, not a file system). Keeping data on the relations ships between files is a nice idea. Putting it in user space is dumb. Its overhead. Look at most of the example he gave "find a word document I worked on last month". All that info is already in the filesystem. A filesystem really is already a database in the strictest since. It stores whats on which inode assoicated with how many blocks which you could think of as attributes. It also sores attibutes like permissions and dates. Why not just put some more attributes into it like subject and relatedtopicID . If you did that and then added the ability to maintain some other tables where you could put extended descriptions and stuff, and built up the query engine to be able to efficently solve queries users will likely ask then you'd have what your really looking for. Addionally you would lose the overhead to a degree because you'd be storing informaiton once instead of in the FS and in the database.

This looks like BLINKX plus more (4, Interesting)

lcsjk (143581) | about 10 years ago | (#10169053)

I already use blinkx, beta, from [] , to automatically search my files along with internet keywords. It doesn't have the search by date or extension and is not configurable to my liking, but it seems to do a good job of finding things I have misplaced. Integrated with the author's system, this could make a great search system.

Normally I file things in a hierarchial method by year and month and by project name (2004file/9sep/) or (2004file/workfile/projectname), but still I lose track now and then and need keywords. Change the "slash" slant to fit your OS.

AVFS - A Virtual File System (2, Interesting)

mooobo (804536) | about 10 years ago | (#10169057)

Have a look at this for a userspace filesystem

There are a debian package called fuse-source and fuse-utils. I.e. use all these nice kio plugins on filesystem level.

Just add

deb unstable main
deb-src unstable main

to your /etc/apt/sources.list

apt-get update
apt-get fuse-source fuse-utils

Actually, I didn't test that yet. Someone else?

Another one... (1)

tenco (773732) | about 10 years ago | (#10169076)

DoXfs []

I hope the FS is better-constructed than this... (-1)

Anonymous Coward | about 10 years ago | (#10169096)

leave how we use the desktop today behind.


higher level of abstractions... (3, Informative)

3seas (184403) | about 10 years ago | (#10169097)

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.

Not a new thing... (1)

lei7 (741439) | about 10 years ago | (#10169112)

The idea of a database-driven file system is nothing new.. try googling for mysqlfs []

Shit.... (1, Offtopic)

Alwin Henseler (640539) | about 10 years ago | (#10169152)

Link points to (University in Enschede, the Netherlands).

My internet connection uses their network, so it may become sluggish for some time, while the /.ing is in effect...

standard filesystems are NOT databases (3, Interesting)

lkcl (517947) | about 10 years ago | (#10169153)

standard filesystems only have ONE index - a hierarchical one that contains a certain amount of real-time-updated indexing (such as the timestamps on a directory)

but it is NOT a relational database: you CANNOT easily create or use an alternative index to your files.

that's what all the fuss is about.

some people mentioned here that they already organise their files. great. fantastic.


and how long would it take to reorganise?

with a relational database, all your indexes are updated AUTOMATICALLY.

therefore, doing searches on a relational database filesystem (find me all music files with dates between last week and last month: SELECT * from files WHERE files.type = "music" and NOW() - 7days

you _can't_ do that sort of thing on a traditional filesystem.

sure, you can emulate it by creating symbolic links all over the place, but what happens when a file is deleted or moved? you need to manage / relocate the symbolic links...



fantastic idea.

now can we have them as a kernel module, pleeease?

Re:standard filesystems are NOT databases (2, Interesting)

mgkimsal2 (200677) | about 10 years ago | (#10169226)

therefore, doing searches on a relational database filesystem (find me all music files with dates between last week and last month: SELECT * from files WHERE files.type = "music" and NOW() - 7days

you _can't_ do that sort of thing on a traditional filesystem.

Argh! Don't say things like that - someone will throw down a shell script which WILL do it (probably in one line) combining find, file, grep, perl/python and some other crap. Which, while it may work for some, entirely misses the real point, is that there's no *easy* way to do this. We've got GUI bindings for opening/saving/editing files, but nothing for harnessing the power of searching. Don't say it can't be done (because it can somehow) just say that it can't be done easily, which is the bigger point. :)

Re:standard filesystems are NOT databases (1)

pandrijeczko (588093) | about 10 years ago | (#10169227)

therefore, doing searches on a relational database filesystem (find me all music files with dates between last week and last month: SELECT * from files WHERE files.type = "music" and NOW() - 7days

you _can't_ do that sort of thing on a traditional filesystem.

This is honestly where I have a problem with the concept of database filesystems and don't understand all the fuss over them.

I can do exactly what you mention above (and more) using a user utility like "find" (in UNIX/Linux).

As far as I'm concerned, if a file-system always knows the names, dates, sizes and locations (on the hard disk) of all my files and does it's best to avoid corruption, what more can I ask of it?

Read the article, read some history (4, Interesting)

eschasi (252157) | about 10 years ago | (#10169160)

To quote from the article (which most folks have not read, as usual):
The DBFS does not actually store files, it holds references to files on the underlying hierarchy based file system.
That line alone should answer many of the questions re backup, speed of FS performance, etc.

At a deeper technical level, nany of the questions asked here have historical answers or clues in The Design and Implementation of the Inversions File System [] . The abstract reads:

This paper describes the design, implementation, and performance of the Inversion file system. Inversion provides a rich set of services to file system users, and manages a large tertiary data store. Inversion is built on top of the
POSTGRES database system, and takes advantage of low-level DBMS services to provide transaction protection, fine-grained time travel, and fast crash recovery for user files and file system metadata. Inversion gets between 30% and 80% of the throughput of ULTRIX NFS backed by a non-volatile RAM cache. In addition, Inversion allows users to provide code for execution directly in the file system manager, yielding performance as much as seven times better than that of ULTRIX NFS.
Note that this paper was published in early 1993. Many of the issues it addresses are relevant to DBFS, and many of DBFS's advantages are foreseen by that paper. IMHO DBFS has chosen a direction that should have better performance than inversion, not to mention lower risk and easier failure recovery.

Inversion was built on POSTGRES, which makes one wonder what happened to the source.

Don't hire him! (1)

Doc Ruby (173196) | about 10 years ago | (#10169214)

"I am currently looking for a job. Interested in employing me? Drop me an email."

Ozy [] has worked on this in his time available as a student. If he gets a job doing something different, he might drop DBFS, and it might die a lonely orphan. Email [] him only with DBFS job offers, please!

whatever happened to the google desktop search? (1)

GuyFawkes (729054) | about 10 years ago | (#10169224)

The smallish (windows) app that you downloaded and in made an index of everything on your PC?

(or was it from altavista?)

Dear ./ crowd (0)

Anonymous Coward | about 10 years ago | (#10169235)

After reading through the comments to this story I have to say I'm sincerely disgusted of you once again.

About 90% of the posters don't even care to read the article.
Now this fact of course doesn't stop you from bitching and whining, on the contrary, it's so much easier if you don't have a clue about what you are talking about.

So as in any story that reports about something new about half the posts consists of "I don't need this, it suxors!!11!!one!", while the other half is busy telling everyone that yet an other project that does the same is hardly needed. Of course the project does something no other project does, but hey, who am I to actually read the article?
I mean I can remember there being other stories about database and filesystem, so hey, this project must be redundant. And if it isn't, who cares, at least I'll be modded insightful by the always competent /. mod crew.

Disgusted as always,

I can't see the gain. (2, Interesting)

The Mighty Git (27891) | about 10 years ago | (#10169237)

A db fs with rich searching of metadata requires the orderly and accurate entry of said metadata.
You can't get organisation out of nothing - you are just asking people to be organised in a slightly different manner.

An organised person can already work effectively in a filesystem with current tools. The fact that they are organised is the key.

A disorganised person is not helped as their metadata will be erratic or absent. In fact might they now have the capability to be even more disorganised?

As I see it this is not solving an organisational problem as much as shifting the interface to the problem. I do not believe it to be either an easier or better way to organise personal data. Conversely I do not believe it to be inherently worse either. It's just different.

Where's the gain?

Re:I can't see the gain. (0)

Anonymous Coward | about 10 years ago | (#10169277)

"A db fs with rich searching of metadata requires the orderly and accurate entry of said metadata."

Argh! Again! I'm getting a headache.
Did it ever occur to you, that applications can produce this metadata and actually do produce this kind of metadata even today?

Don't you guys have mp3s?

Re:I can't see the gain. (1)

The Mighty Git (27891) | about 10 years ago | (#10169284)

That's not metadata - that's data embedded in the file. I already have tools to deal with those and they are more than adequate.

Where's the gain?

Apple's Spotlight (4, Informative)

DuckWing (19575) | about 10 years ago | (#10169287)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>