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

yftty

http://bbs.chinaunix.net/forum/viewtopic.php?show_type=&p=4223184#4223184

coolzhh

老兄,可以另开一个地方开始项目吧
这里面都几十页,不太方便看了

yftty

呵呵, 好的, 可以建立个网站了

xichen

建议你从
http://wiki.woodpecker.org.cn/moin/Compass/CompassSysfile
找点思路。
恩。

yftty

好, 谢谢 ! 学习ing中...

yftty

http://www.phy.duke.edu/resources/computing/brahma/Resources/beowulf_book.php
is a good start,
http://www.beowulf.org is another good place, it is also the home of the
original beowulf mailinglist.

Generally I would recommend digging through recent mailinglist postings
because
there are often very informed answers to questions.

Lon just answered a fencing question a few days ago:

"STONITH, STOMITH, etc. are indeed implementations of I/O fencing.

Fencing is the act of forcefully preventing a node from being able to
access resources after that node has been evicted from the cluster in an
attempt to avoid corruption.

The canonical example of when it is needed is the live-hang scenario, as
you described:

1. node A hangs with I/Os pending to a shared file system
2. node B and node C decide that node A is dead and recover resources
allocated on node A (including the shared file system)
3. node A resumes normal operation
4. node A completes I/Os to shared file system

At this point, the shared file system is probably corrupt.  If you're
lucky, fsck will fix it -- if you're not, you'll need to restore from
backup.  I/O fencing (STONITH, or whatever we want to call it) prevents
the last step (step 4) from happening.

How fencing is done (power cycling via external switch, SCSI
reservations, FC zoning, integrated methods like IPMI, iLO, manual
intervention, etc.) is unimportant - so long as whatever method is used
can guarantee that step 4 can not complete."

"GFS can use fabric-level fencing - that is, you can tell the iSCSI
server to cut a node off, or ask the fiber-channel switch to disable a
port.  This is in addition to "power-cycle" fencing."


Michael

--
Linux-cluster mailing list

yftty

Google 搜索技术交流会报名
http://bbs.chinaunix.net/forum/viewtopic.php?t=631871

请提出对此次交流内容的意见和建议, 或者需要加入的内容, 从而令我们能够更多的从技术层面了解这个互联网乃至计算机行业的"跑路者".

注: 本此交流会为民间行为, 内容也是网上公开的信息, 如和某组织,个人相关事物有冲突, 请立即联系, 笔者会作相应修改.

yftty

以后的交流平台要转移到 www.googlefs.com 上去了， 请先看看这里 http://bbs.chinaunix.net/viewthr ... &extra=page%3D1

yftty

http://channel9.msdn.com/Showpost.aspx?postid=142120

A journaling file system will ensure that individual metadata changes are atomic (such as creating directory entries, renaming files, etc.).  It only applies to one change.  If your system crashes, the file structure itself will be correct, but the data in your files might not be.

A logging file system (terminology is sometimes different), both the metadata and the actual data are journaled.  This allows it to make sure the contents of the file are correct, but it still only works on one operation.

A transactional file system (AFAICT for Vista) will do both data and metadata over many modifications.  So, you can create and modify many files atomically (either everything is done or nothing is done).

It's nice to see Microsoft moving us out of the stone age.  Trying to write safe file-system modification routines on most file systems is tricky (using atomic rename tricks and such) and requires a lot of "check for cleanup" code during startup if you want to handle it properly.  I work on systems that cannot fail (embedded systems where nobody can administrate them), and would really love something like this.

veiven26

先支持一下，只是不知道要参与这个项目的话需要先学会哪些知识？