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]
Message-ID: <20090114002008.GD512@ioremap.net>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ