linux-kernel - Re: [0/7] Distributed storage for drivers/staging merge request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Jan 2009 03:20:08 +0300
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Greg KH <greg@...ah.com>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, dst@...emap.net
Subject: Re: [0/7] Distributed storage for drivers/staging merge request

On Wed, Jan 14, 2009 at 03:15:46AM +0300, Evgeniy Polyakov (zbr@...emap.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/