From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Jeff Garzik <jeff@garzik.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: POHMELFS high performance network filesystem. Transactions, failover, performance.
Date: Wed, 14 May 2008 11:57:56 +0400 [thread overview]
Message-ID: <20080514075756.GC28330@2ka.mipt.ru> (raw)
In-Reply-To: <20080514005223.GE27483@shareable.org>
On Wed, May 14, 2008 at 01:52:23AM +0100, Jamie Lokier (jamie@shareable.org) wrote:
> I feel you have glossed over the more difficult parts of transactions
> and cache coherency etc. with this brief summary ;-)
It was (and is) also a different time zone here :)
> Yours does sound a very interesting project. Do you know how it
> compares with NFSv4 for performance? I think that has some similar
> caching abilities? I think CRFS should be similar.
NFSv4 does not use similar caching scheme, but it has interesting
batching abilities for bulk data transfer. CRFS was originally a source
of inspiration for this project (before it was opened, we had some talk
with Zach Brown, so I decided that it worth deeper investigation and
started this FS). CRFS performance is also very good, but the fact, that
it is only limited to BTRFS server seriously limits its usage imho.
> > As practice shows, the smaller and simpler initial steps are, the better
> > results eventually become :)
>
> I think you are right. I am struggling with the opposite approach
> (too big steps, trying to be too clever with algorithms) on a similar
> project! That said, I did try simpler steps earlier, and it worked
> but showed a lot of tricky problems.
The more we develop, more problems arises, so it is possible (and I had
such situation), when very complex, but solvable problem, during
development translates into multiple problems of the same complexity,
which takes more and more time... Essentially this can be solved, until
something is dropped and added when other things are completed.
For example there is a really interesting lockless algorithm for storing
path cache in the POHMELFS, but implementation is really complex, so I
used much simler tree based one, and things scale good even with it.
> Fwiw, I've been working on what started as a distributed database that
> is coming to be a filesystem too. It has many qualities of both,
> hopefully the best ones. I'm aiming for high LAN file performance
> similar to what you report with POHMELFS and would expect from any
> modern fs, while also supporting database style transactions and
> coherent queries, in a self-organising distributed system that handles
> LAN/WAN/Internet each at their best. Mention of Paxos stirred me to
> reply - a relative of that is in there somewhere. I have a long way
> to go before a release.
Depending on what to call a release :)
> If anyone is working on something similar, I would be delighted to
> hear from them.
I belive that (only block?) FS which exports its structure in database
accessible way, i.e. ability to search objects not only by name key and
assign that new keys similar to how it is done in database, but not via
assign_xattr(search(name)), is a very interesting and useful approach.
Also the more I follow general purpose fs developments, the more I
become sure that they (general purpose) will never be the best on any
given workload, and instead special purpose (like databasefs or
whatever) filesystems will get the niche. IMHO of course.
> It scares me that I'm actually trying to do this. But very exciting
> it is too.
Scares problems which we can not solve, this one kind of increases
adrenalin level :)
> It seems there's quite a bit of interesting work on Linux in this area
> right now, with BTRFS and CRFS too.
Yeah, probably this is time to move further in given area, so lots of
interesting new developments.
--
Evgeniy Polyakov
next prev parent reply other threads:[~2008-05-14 7:58 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-13 17:45 POHMELFS high performance network filesystem. Transactions, failover, performance Evgeniy Polyakov
2008-05-13 19:09 ` Jeff Garzik
2008-05-13 20:51 ` Evgeniy Polyakov
2008-05-14 0:52 ` Jamie Lokier
2008-05-14 1:16 ` Florian Wiessner
2008-05-14 8:10 ` Evgeniy Polyakov
2008-05-14 7:57 ` Evgeniy Polyakov [this message]
2008-05-14 13:35 ` Sage Weil
2008-05-14 13:52 ` Evgeniy Polyakov
2008-05-14 14:31 ` Jamie Lokier
2008-05-14 15:00 ` Evgeniy Polyakov
2008-05-14 19:08 ` Jeff Garzik
2008-05-14 19:32 ` Evgeniy Polyakov
2008-05-14 20:37 ` Jeff Garzik
2008-05-14 21:19 ` Evgeniy Polyakov
2008-05-14 21:34 ` Jeff Garzik
2008-05-14 21:32 ` Jamie Lokier
2008-05-14 21:37 ` Jeff Garzik
2008-05-14 21:43 ` Jamie Lokier
2008-05-14 22:02 ` Evgeniy Polyakov
2008-05-14 22:28 ` Jamie Lokier
2008-05-14 22:45 ` Evgeniy Polyakov
2008-05-15 1:10 ` Jamie Lokier
2008-05-15 7:34 ` Evgeniy Polyakov
2008-05-14 19:05 ` Jeff Garzik
2008-05-14 21:38 ` Jamie Lokier
2008-05-14 19:03 ` Jeff Garzik
2008-05-14 19:38 ` Evgeniy Polyakov
2008-05-14 21:57 ` Jamie Lokier
2008-05-14 22:06 ` Jeff Garzik
2008-05-14 22:41 ` Evgeniy Polyakov
2008-05-14 22:50 ` Evgeniy Polyakov
2008-05-14 22:32 ` Evgeniy Polyakov
2008-05-14 14:09 ` Jamie Lokier
2008-05-14 16:09 ` Sage Weil
2008-05-14 19:11 ` Jeff Garzik
2008-05-14 21:19 ` Jamie Lokier
2008-05-14 18:24 ` Jeff Garzik
2008-05-14 20:00 ` Sage Weil
2008-05-14 21:49 ` Jeff Garzik
2008-05-14 22:26 ` Sage Weil
2008-05-14 22:35 ` Jamie Lokier
2008-05-14 6:33 ` Andrew Morton
2008-05-14 7:40 ` Evgeniy Polyakov
2008-05-14 8:01 ` Andrew Morton
2008-05-14 8:31 ` Evgeniy Polyakov
2008-05-14 8:08 ` Evgeniy Polyakov
2008-05-14 13:41 ` Sage Weil
2008-05-14 13:56 ` Evgeniy Polyakov
2008-05-14 17:56 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080514075756.GC28330@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=jeff@garzik.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.