浩存 - 面向数据库，虚拟机等海量数据可同时提供NFS/iSCSI访问的集群存储系统

yftty

http://bbs.chinaunix.net/forum/viewtopic.php?t=588832

freebsd开发小组对内核的代码审查非常严格，绝大部分是开发小组编写的，代码得到充分的优化，很大程度上保持的代码的执行效率和安全性。另外，代码保证了BSD许可得到体现，也就是说有内核的代码和采用的技术都是freebsd开发小组所有，没有侵权的危机，在freebsd上开发的软件可以开源，也可以不开源，可以是免费，也可以共享或商业软件。但因为freebsd代码审查和开发太严格，导致很多新技术在freebsd上出现是很缓慢的，例如freebsd对smp的支持。
   linux的代码中很大部分是世界各地开发者贡献的，虽然新技术体现得很快，但面临这维护困难，版权的问题。维护困难是指开发者可能由于各种原因不继续开发了，而且开发者的技术水平不一，代码的优化和安全性得不到保障；版权是指代码本身和使用的技术可能涉及到商业版权，甚至是公司行为，大公司有意的贡献自己的代码，造成linux使用面临着侵权的危险，sco告IBM就是一个很好的例子。
  linux成立开发小组后，由于后继开发的版本都是在前面版本的基础上进行的，虽然不能一下子改变这个局面，但通过严格的审查和代码发布控制，相信情况是会慢慢好转起来的。linus torwalds前一段时间表示，在2.6版本开发出来以后，将会把工作重点转移到代码的优化，安全性和稳定性方面

suran007

我们服务器原来用的是ＮＦＳ共享存贮，后来改的ＧＦＳ，但是现在很慢，服务器资源消耗很大，可是网上都说ｇｆｓ比ｎｆｓ要性能更优异,那位朋友有做过GFS的，说说怎么讲GFS性能设置得更优异一些
急等回复，那位大侠帮帮我，我的qq24242546

yftty

[quote]原帖由 "suran007" 发表：
我们服务器原来用的是ＮＦＳ共享存贮，后来改的ＧＦＳ，但是现在很慢，服务器资源消耗很大，可是网上都说ｇｆｓ比ｎｆｓ要性能更优异,那位朋友有做过GFS的，说说怎么讲GFS性能设置得更优异一些
急等回复，那位大侠

yftty

Daniel Phillips

Hi guys,

I'm interested in helping pull on the oars to help get the rest of the way to
Posix compliance.  On the "talk is cheap" principle, I'll start with some
cheap talk.

First, you don't have to add range locks to your DLM just to handle Posix
locks.  Posix locking can be handled by a completely independent and crude
mechanism.  You can take your time merging this with your DLM, or switching
to another DLM if that's what you really want to do.

In the long run, the DLM has to have range locking in order to implement
efficient, sub-file granularity caching, but the VFS still needs work to
support this properly anyway, so there is no immediate urgency.  And Posix
locking is even less of a reason to panic.

Now some comments on how the hookable Posix locking VFS interface works.
First off, it is not a thing of beauty.  The principle is simple.  By
default, the VFS maintains a simple minded range lock accounting structure.
It is just a linear list of range locks per inode.  When somebody wants a new
lock, the VFS searches the whole list to find collisions.  If a lock needs to
be split, merged or whatever, these are very basic list operations.  The code
is short.  It is obviously prone to efficiency bugs, but I have not heard
people complaining.

The hook works by simply short-circuiting into your filesystem just before the
VFS touches any of its own lock accounting data.  Your filesystem gets the
original ioctl arguments and you get to replicate a bunch of work that the
VFS would have done, using its own data structure.  There are about 5
shortcircuits like this.  See what I mean by not beautiful?  But it is fairly
obvious how to use this interface.

On a cluster, every node needs to have the same view of Posix locks for inodes
it is sharing.  The easiest way I know of to accomplish this is to have a
Posix lock server in the cluster that keeps the same, bad old linear list of
locks per Posix-locked inode, but exports operations on those locks over the
network.  Not much challenge: a user space server and some tcp messaging.
The server will count the nodes locking a given inode, and let the inode fall
away when all are done.  I think inode deletion just works: the filesystem
just has to wait for confirmation from the lock server that the Posix locks
are dropped before it allows the normal delete path to continue.

Inodes that aren't shared don't require consulting the server, an easy
optimization.

For failover, each node will keep its own list of Posix locks.  Exactly the
same code the VFS already uses will do, just cut and paste it and insert the
server messaging.  To fail over a lock server, the new server has to rollcall
all cluster nodes to upload their Posix locks.

Now, obviously this locking should really be distributed, right?  Sure, but
notice: the failover algorithm is the same regardless of single-server vs
distributed; in the DLM case it just has to be executed on every node for the
locks mastered on that node.  And oh, you have to deal with a new layer of
bookkeeping to keep track of lock masters, and fail that over too.  And of
course you want lock migration...

So my purpose today is to to introduce the VFS interface and to point out that
this doesn't have to blow up into a gigantic project just to add correct
Posix locking.

See here:

  http://lxr.linux.no/source/fs/locks.c#L1560
  if (filp->;f_op && filp->;f_op->;lock) {

Regards,

Daniel
_______________________________________________
Ocfs2-devel mailing list

yftty

http://bbs.chinaunix.net/forum/46/050807/589800.html

新浪科技讯 北京时间8月6日消息

    AOL日前宣布已收购网络存储公司Xdrive，以满足消费者对收集数字音乐、图片及其它文件的需求。目前，这一交易涉及的具体金额还没有披露。

    AOL表示，今后Xdrive将成为其全资子公司，继续通过Xdrive.com销售存储和备份服务。目前，Xdrive公司的34名员工已经转到AOL位于加州圣莫尼卡的总部办公。分析人士认为， AOL可能会在自己的现有服务中集成Xdrive技术，就像该公司去年收购反垃圾邮件公司Mailblocks之后所采取的一系列举措一样。通过Xdrive平台，AOL可以实现电子邮件、网络日志、图片以及其它服务的集中存储。到目前为止，AOL还没有提供更多细节。

    近年来，AOL对于存储的需求持续增长。不久前，AOL开始通过“aim.com”为用户提供免费的电子邮箱，同时还为付费用户提供不限容量的电子邮箱存储空间。AOL希望通过此举吸引更多用户，提升自身竞争力。AOL的主要竞争对手Google已经推出了2GB的免费电子邮箱。AOL发言人尼古拉斯 -格拉汉姆(Nicholas Graham)，随着越来越多的家庭开始使用宽带网络，通过网络传输数字视频、电影等大文件逐渐成为可能，消费者对于存储的需求将日益增长。

    格拉汉姆同时称，AOL并不会从头开始打造一个新的存储系统，因为Xdrive公司在这一领域已经投入了数百万美元的资金和数百名工程师的努力。(摩尔）

CU_runner

34人就运营了一个存储公司，老外真牛呀

secondself

rtsp://vodreal.stanford.edu/sns/0506/jobs.rm

Stay hungry, stay foolish !

yftty

http://tech.sina.com.cn/i/2005-08-15/0924692923.shtml

...

    微软做的调查发现，用户对于邮件系统的需要，第一位是稳定性、第二位是安全性，排在第三位才是邮箱的容量大小。罗川认为，邮件首先要满足最基本的功能，是要能够很稳定地收发邮件，人家发的你要能够收到，发出去的要能够很顺利地发出去。其次，所谓安全性目前来讲很重要的就是能够过滤掉垃圾邮件。罗川说:“如果邮箱容量很大，但这里头收到很多垃圾邮件，没有办法找到自己真正的信息，用户不会对这样的邮箱满意。”

...

　　目前微软有两套邮件服务产品。一个是基于网络的Hotmail，另外一个是基于客户端的 Outlook系列。相对目前的微软邮箱产品，将要推出的下一代以网络为基础的邮件体系能够跟客户端邮件的体系功能一样强大。也就是说像通讯录等原来存在个人电脑上的信息存在了网络邮件系统。

...

yftty

From: Payal Rathod

Hi,
The whole filesystem idea is seemingly interesting to me. Can someone
point to some good documentation which explains superblock, inode block
and data blocks in details without going into too much of technicalities
(as I am a person with no technical background academically).

==================================================================

From: Matt Stegman

This page is all about ext2, not reiserfs, but I think it works as a good
primer for general information:

http://web.mit.edu/tytso/www/linux/ext2intro.html

This page provides more detailed information about reiserfs (that's
version 3, not 4, just to be clear):

http://homes.cerias.purdue.edu/~florian/reiser/reiserfs.php

If you're not familiar with the basic ideas behind hard disks and
partitions, and the difference between a partition and a filesystem,
Ranish's partitioning primer does a good job of explaining that.

http://www.ranish.com/part/primer.htm

yftty

http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2005/7292.html

From: Ivan Popov

Hi,

some days ago I found an insightful comment on a slashdot story about Google.

If Coda-alike is going to be written from scratch, it might be Google who does that... or anyone who sees the potential and has enough money.

Coda did it right, just evolved too slowly to come in time, or may be we still have a chance?

I mean a chance to have a full-scale free technology instead of a proprietary one

which otherwise would fill the niche and attract (and force) the community to use and pay for the technology, besides the services?

Coda is still unique, and there is a clear interest for global file service... Now it _is_ possible to use Coda for making money, offer services and be paid for them, not for the technology.

http://daltonlp.com/daltonlp.cgi?item_type=0&item_id=424

...

Comment by Mystified
...

Personally, I think it makes massive sense to build a "desktop" stack of applications delivered over the internet and with centrally stored, encrypted data and to sell that service on a recurring subscription basis. If the apps worked across platforms from my laptop to my cell phone and provided easy access to the knowledge of the world, I would seriously think about paying that monthly fee (provided they did not spam me with targetted ads or sell my PII).
...

The applications delivery is already taken care of by Konvalo.org. A decent "homedir" service with an application environment will fit nicely for those needs.

=====================================================================

From: Gabriel B.

I think that Plan9 would be better suited for that google OS idea. but it's getting way of topic Back to coda:
...