Longhorn FS being removed to Blackcomb (end of decade)

Longhorn FS being removed to Blackcomb (end of decade)

[Burnes, James]

Just thought this might be interesting to some of you.  The
database-like FS for Longhorn has just been delayed until the end of the
decade.  That's great.  It means that Microsoft's attempt to copy the
BeOS filesystem is not meeting with much success.

Which leads to my follow on...

I think I remember database-like file system capabilities in Reiser are
scheduled for V5? Or could it be done with plugins?

It would be great to beat MS to the DB filesystem punch.  Maybe with
object-oriented plugins in V4 that won't matter as much.

BTW: I was thinking about Squid performance this morning vs. Cacheflow.
Has anyone considered that a special V4 plugin for Squid might really
boost it's performance.

Just thinking out loud....

(Hans in the background: You want more features, how about writing it
yourself.  I mumble something about being in the middle of a move to
Denver).


jim burnes
security engineer
great-west, denver
 

Re: Longhorn FS being removed to Blackcomb (end of decade)

[Hubert Chan]

>>>>> "James" == Burnes, James <james.burnes@gwl.com> writes:

James> Just thought this might be interesting to some of you.  The
James> database-like FS for Longhorn has just been delayed until the end
James> of the decade.  That's great.  It means that Microsoft's attempt
James> to copy the BeOS filesystem is not meeting with much success.

From the article[1]:

  The current plan calls for the file system to work on PCs but not
  extend to files shared over a corporate network.

[1] http://yahoo.businessweek.com/magazine/content/04_16/b3879009_mz001.htm

So it looks like WinFS will still be in Longhorn, but with scaled-back
capabilities.  (Of course, with Microsoft, you never really know what to
expect.)  So it sounds like Reiser6, without the Reiser5 stuff (IIRC,
Reiser6 adds the database capabilities, and Reiser5 is a distributed
filesystem, and the order in which they will appear depends on
funding).

Given how long it took Reiser4 to materialize, I'm not too confident
that Reiser6 will appear before Longhorn.  But then again, Reiser4 was
a complete rewrite, while Reiser6 should be mostly just new plugins.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Longhorn FS being removed to Blackcomb (end of decade)

[Jonathan Briggs]

On Fri, 2004-04-09 at 11:32, Burnes, James wrote:
> Just thought this might be interesting to some of you.  The
> database-like FS for Longhorn has just been delayed until the end of the
> decade.  That's great.  It means that Microsoft's attempt to copy the
> BeOS filesystem is not meeting with much success.
> 
> Which leads to my follow on...
> 
> I think I remember database-like file system capabilities in Reiser are
> scheduled for V5? Or could it be done with plugins?
> 
> It would be great to beat MS to the DB filesystem punch.  Maybe with
> object-oriented plugins in V4 that won't matter as much.
[snip]

I've been thinking about the filesystem database idea a lot recently. 
I'm not a famous database or filesystem designer, but I've got opinions
:-)

I think the best way to be doing database features is with a fast,
robust file change notification feature, and do the database in user
space.  Some filesystem features would be required, but I think metadata
and two-way hard links is all we need.

I came to the conclusion that doing the search and indexing in the
filesystem isn't necessary if a userspace daemon can track file and
metadata changes and update index/search directories with hard links. 
One of the Reiser4 pseudo files needs to be a list of hard links to the
file, so the daemon can find each reference and update or delete links
as needed.

The daemon could watch directory creation and look for query metadata on
directories.  When found, it would use index directories or full
filesystem search to fill in the query results.

I think we could do this in Reiser4.  Some of the security auditing work
being done in the kernel could be adapted for filesystem change
notification.  Then we need some Reiser4 plugins for tracking hard links
and metadata.  Then we need the daemon to watch file changes and create
index and query results.

Whee!  I make it sound so easy!

> (Hans in the background: You want more features, how about writing it
> yourself.  I mumble something about being in the middle of a move to
> Denver).

Hey, great!  I'm living near Boulder (close to Denver) and I love it
here.  I think you will too.
-- 
Jonathan Briggs
jbriggs@esoft.com

Re: Longhorn FS being removed to Blackcomb (end of decade)

[Stewart Smith]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Sat, 2004-04-10 at 05:33, Jonathan Briggs wrote:
> I think the best way to be doing database features is with a fast,
> robust file change notification feature, and do the database in user
> space.  Some filesystem features would be required, but I think metadata
> and two-way hard links is all we need.

Symbolic links would quite possibly work better - as then you can
extract the path of the original file, and with the manipulation of
these symlinks being part of the file manipulation atom (as in, an
atomic operation), consistency wouldn't be a problem.

> The daemon could watch directory creation and look for query metadata on
> directories.  When found, it would use index directories or full
> filesystem search to fill in the query results.

You have a lot of consistency problems here. Consider this:
1. process 1 creates file
2. kernel tells userspace to index it
CRASH

the userspace daemon hasn't had time to put it into the index. On
reboot, how do you get a list of files to insert into the index without
scanning every single file on disk (essentially a fsck)? You can't - so
you're in trouble. You could have a to-be-indexed directory of hard/sym
links where as the userspace utility flushes the index of the item to
disk, it is removed from there. That could work... but it requires the
creat() (etc) operations to also create this link atomically, otherwise
you could create the file, but not have it in the "to be indexed" list.

It's for these kinds of reasons that all the befs indexing stuff is all
in kernel.

-- 
Stewart Smith (stewart@flamingspork.com)
http://www.flamingspork.com/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]