public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <zbr@ioremap.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	dst@ioremap.net
Subject: Re: [0/7] Distributed storage for drivers/staging merge request
Date: Wed, 14 Jan 2009 03:20:08 +0300	[thread overview]
Message-ID: <20090114002008.GD512@ioremap.net> (raw)
In-Reply-To: <20090114001546.GC512@ioremap.net>

On Wed, Jan 14, 2009 at 03:15:46AM +0300, Evgeniy Polyakov (zbr@ioremap.net) wrote:
> > Whereas the "do we need this" case for new filesystems isn't this simple.
> 
> More on this, it is a block device which does not work with hardware.
> And yes, question is serious. And you may not believe, but it is not me
> to answer this. I'm happy to provide any needed information.
> In a nutshell, it is a network block device on really huge steroids.

And according to POHMELFS which is a parallel very high-performance
(forget nfs) network filesystem with coherent local cache of data
and metadata.

The only change expected to be done is one additional network command
to parse the data currently sent via netlink. We want to connect to the
new servers by another server request and not by admin steps.

Patch will be somewhat 10-50 lines. And while you at it, please shed a
light on this exports for POHMELFS:

--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -513,6 +513,7 @@ int add_to_page_cache_lru(struct page *page, struct address_space *mapping,
 	}
 	return ret;
 }
+EXPORT_SYMBOL_GPL(add_to_page_cache_lru);
 
 #ifdef CONFIG_NUMA
 struct page *__page_cache_alloc(gfp_t gfp)
@@ -627,6 +628,7 @@ int __lock_page_killable(struct page *page)
 	return __wait_on_bit_lock(page_waitqueue(page), &wait,
 					sync_page_killable, TASK_KILLABLE);
 }
+EXPORT_SYMBOL_GPL(__lock_page_killable);
 
 /**
  * __lock_page_nosync - get a lock on the page, without calling sync_page()



-- 
	Evgeniy Polyakov

  reply	other threads:[~2009-01-14  0:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-13 23:05 [0/7] Distributed storage for drivers/staging merge request Evgeniy Polyakov
2009-01-13 23:05 ` [1/7] dst: core files Evgeniy Polyakov
2009-01-13 23:05   ` [2/7] dst: network state machine Evgeniy Polyakov
2009-01-13 23:05     ` [3/7] dst: export node Evgeniy Polyakov
2009-01-13 23:05       ` [4/7] dst: thread pool Evgeniy Polyakov
2009-01-13 23:05         ` [5/7] dst: transactions Evgeniy Polyakov
2009-01-13 23:05           ` [6/7] dst: crypto processing Evgeniy Polyakov
2009-01-13 23:05             ` [7/7] dst: kconfig and makefile changes Evgeniy Polyakov
2009-01-13 23:09               ` [8/7] dst: kconfig update Evgeniy Polyakov
2009-01-14  2:22                 ` Randy Dunlap
2009-01-14  9:09                   ` Evgeniy Polyakov
2009-01-14  2:22               ` [7/7] dst: kconfig and makefile changes Randy Dunlap
2009-01-14 14:46         ` [4/7] dst: thread pool Frederik Deweerdt
2009-01-14 15:01           ` Evgeniy Polyakov
2009-01-15  5:58         ` Andrew Morton
2009-01-15  8:47           ` Evgeniy Polyakov
2009-01-19  0:10           ` Arjan van de Ven
2009-01-19 17:07             ` Evgeniy Polyakov
2009-02-05 13:55             ` David Howells
2009-01-14 14:52       ` [3/7] dst: export node Jens Axboe
2009-01-14 15:11         ` Evgeniy Polyakov
2009-01-13 23:39 ` [0/7] Distributed storage for drivers/staging merge request Greg KH
2009-01-13 23:47   ` Evgeniy Polyakov
2009-01-14  0:01     ` Greg KH
2009-01-14  0:08       ` Evgeniy Polyakov
2009-01-14  0:12       ` Andrew Morton
2009-01-14  0:15         ` Evgeniy Polyakov
2009-01-14  0:20           ` Evgeniy Polyakov [this message]
2009-01-14  0:23             ` Andrew Morton
2009-01-14  0:24               ` Evgeniy Polyakov
2009-01-14  9:39               ` Jeff Garzik

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=20090114002008.GD512@ioremap.net \
    --to=zbr@ioremap.net \
    --cc=akpm@linux-foundation.org \
    --cc=dst@ioremap.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox